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using a wireless communication link 110, such as over a 
cellular telephone system. A position system, such as a set of 
GPS satellites 140, provides positioning signals that are used 
by the in-vehicle systems, and optionally by the centralized 
server system to increase the accuracy of position estimates. 
In one version of the system, an operator specifies a desti- 
nation to an in-vehicle system which validates the destina- 
tion. The in-vehicle system transmits specification of the 
destination to a server system 125 at the centralized server. 
The server system computes a route to the destination and 
transmits the computed route to the in-vehicle system. The 
in-vehicle system guides the operator along the route. If the 
in-vehicle system detects that the vehicle has deviated from 
the planned route, it replans a new route to the destination 
using an in-vehicle map database. 
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VEHICLE INFORMATION SYSTEM Id general, in another aspect, the invention is a method for 

guiding a vehicle through a road network from a starting 
CROSS-REFERENCE TO RELATED location to a destination. The method features transmitting a 

APPLICATIONS specification of the destination to a server, for example by 

This application is a continuation of U.S. application Ser. s transmitting a street address or an identifier of a point of 

No. 09/136.868, filed Aug. 19, 1998, which claims the f^ 651 ;. 11,6 f,™ d f rmmes :„ a , r ? utc ° the 

^ i-iron if i- • vi ^^r^^r/^ci j destination and transmits a specification of the route to the 

benefit of ^Provisional Application No. 60056,150, filed ^ meth(x) a]so receiving from , he m[ 

Aug. iv, lyy/. a specification of a planned route through the road network 

BACKGROUND jq to me destination as well as receiving from the server a map 

_ . . , . r . r that includes a specification of the road network in the 

This invention relates to an information system for motor vicmhy of , he planned rou(e For the map caQ 

vemcies. correspond to one or more regions around particular points 

Vehicle information systems have been developed that 0D tne p i anne d route, correspond to a "corridor" around the 

provide various types of information to operators of those planned route, or be a complex shaped region in the vicinity 

vehicles. In particular, navigation systems have been devel- Q f me roule -r^ planned route can include specifications of 

oped. One type of navigation system, an autonomous navi- a multiple maneuvers to be carried out by the vehicle, and 

gation system, uses an on-board map, typically stored on a me specification of each maneuver then includes a location 

removable medium such as a compact optical disk (e.g., of the maneU ver. The map can be in the vicinity of the 

CD-ROM). The navigation system uses the on-board map to starting location, or in the vicinity of one of the specified 

plan a route from a starting point to a destination, which is maneuvers. The method can also feature tracking the loca- 

specified by the operator of the vehicle. Updating an autono- ^on 0 f tne vehicle. The method can also feature displaying 

mous system's map, for example to add or correct the received map in conjunction with a representation of the 

information, typically involves replacing the removable planned route, and a location of the vehicle, 

medium. 25 An advantage of the invention is that the vehicle does not 

In some navigation systems the operator inputs the have to have a prestored map to plan a route to a destination, 

desired destination (and the current location, if required by Also, the invention provides a way of displaying a map of 

the system) by entering a spelling of the destination. Some the vicinity of the starting point or of intermediate maneuver 

systems also allow an operator to select from a stored list of points of a planned route without requiring that the map be 
"points of interest," such as a list of gas stations or restau- ^ prestored in the vehicle. The displayed map can provide 
_rants^Once the operator inputs the destination, the sysTem~ 4y_ ' use f u i information to an operator of a vehicle during difficult 

plansa route along the road network to the destination. The maneuvers where turn-by-turn instructions, 

route is typically planned to provide ashortest distance orto In generaU in mQlhc[ thc ^ a mcthod for 

try to provide the shortest travel time. OncTlhTToufeTs^ tracking a vehicle. The method features receiving a refer- 

planned, the operator is guided by the system along the 3J cnce signal from a pos iti 0 ning system, for example receiv- 

rautc ' ing signals from GPS satellites, and computing position data 

Various approaches to route guidance have been used. A related to the location of the vehicle using the received 

particularly simple approach is to provide the operator with reference signal. For example, the position data can be 

a sequence of discrete instructions, for instance, at intersec- latitude and longitude estimates, or can be GPS pseudorange 

tions where the operator must turn from one street onto ^ measurements. The method also features transmitting the 

another. The operator indicates when he or she is ready for position data to a server and receiving from the server 

the next instruction. For example, the instructions are pro- position correction data. For example, the position correc- 

vided as an audio output, and the operator says "next" when tio D C an be a deviation in latitude and longitude, or can be 

ready for another instruction. correction terms to be applied to GPS pseudorange mea- 

Another approach to route guidance uses a displayed map 45 surements. The method also features determining estimated 

on which the planned route and the vehicle's location are coordinates of the vehicle including combining data com- 

dynamically displayed. The operator uses the map to decide puted from the received reference signal and the position 

when and where to turn in order to follow the planned route. correction data. 

Some guidance approaches are aided by in -vehicle sen- The method can feature repeatedly computing the position 

sors that are used to estimate the location of the vehicle. For 50 data, and determining the estimated coordinates, including 

instance, a magnetic compass is used to estimate the direc- combining the position data and the position correction data, 

tion of travel, and a velocity sensor is used to estimate the The method can also feature, subsequent to the interval of 

distance traveled. In addition, the location of the vehicle can time, repeatedly computing the position data and determin- 

be estimated using the Global Positioning System (GPS). In ing estimated coordinates of the vehicle using the position 

GPS, multiple satellites emit signals that allow an in-vehicle 55 data without using the correction data. 

GPS receiver to estimate its absolute location. In general, in another aspect, the invention is a method for 

Other types of vehicle information systems have also been tracking a vehicle. The method features receiving a speci- 

developed. In some systems, traffic related information, such fication of a first location which includes coordinates, such 

as traffic advisories, is broadcast to specially equipped as latitude and longitude, of the first location. The method 

in-vehicle radio receivers. 60 includes determining when the vehicle is at or passes near 

the first location. The method includes computing first 

bUMMAKi position data using a reference signal received from a 

In general, in one aspect, the invention is a vehicle positioning system at the time at which the vehicle was 

information system. The vehicle information system fea- determined to be at the first location. For instance, the 

tures an in-vehicle system and a centralized server system. 65 positioning system can be a GPS positioning system, and the 

The in-vehicle system communicates with the server system computed first position data can include pseudorange mea- 

using a wireless communication link. surements derived from GPS satellite signals received when 
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the vehicle was at or near the first location. The method database using the received validated location specification, 

further includes computing position correction data using In addition the method can also include determining a route 

the first position data and the coordinates of the first loca- to the specified location using the server map database, and 

lion. For instance, computing the position correction data transmitting the determined route to the in-vehicie system, 

can include computing pseudorange correction data based 5 In general, in another aspect, the invention is method for 

on the latitude and longitude of the first location and on the estimating a location of a vehicle. The method includes 

pseudorange measurements derived from GPS satellite sig- determining a series of vehicle position estimates using a 

nals received when the vehicle was at or near the first positioning system, and recording each of the vehicle posi- 

location. The method further includes computing second U0D estimates in the series. For example, the position 

position data using a reference signal received from the 10 reco ^ ed m a ™ n - vola " le , as the 

positioning system at a second lime subsequent to the time vehicle reaches a destination. The method further includes 

at which that the vehicle was determined to be at the first ff™** thc tl locatlOD , ° f Mc K « l ™ Q Z 

, tl _ . . .. t , . the most recently recorded in the series of location estimates, 

location, and then determining coordinates of the vehicle at fof ^ tbe vehide fe sUrted flfter a riod of bej 

the second time including combining the correction data and parke(J at the destination> 

the second position data. 15 The invention has the advantage that a location estimate 

The method can feature including in the specification of may t, e obtained, even if a positioning system, such as a GPS 

the first location a specification of a maneuver to be carried satellite system, is out of range, or prior to the positioning 

out by thc vehicle at the first location. Determining when the system being initialized. 

vehicle is at the first location then includes detecting when Jn g ener al, in another aspect, the invention is a method for 

the vehicle performs the specified maneuver, for instance 20 veD j c j e guidance. The method features receiving at the 

using vehicle sensors such as a compass, accelerometers, or vehicle a planned route to a destination location from a 

a gyroscope. server, and storing the planned route at the vehicle. The 

In general, in another aspect, the invention is a method for method also includes providing instructions to an operator of 

detecting when a vehicle deviates from a planned route. The the vehicle according to the stored planned route, for 

method features tracking a first estimated position of the 25 example, providing instructions at each of a series of maneu- 

vehicle using signals from a positioning system that are vers along the route. The method includes tracking a loca- 

received at the vehicle, for example, using a GPS position- tion of the vehicle and detecting whether the vehicle has 

ing system. The method also features tracking a second deviated from the planned route. If the vehicle is detected to 

estimated position of the vehicle using an estimate of the have deviated from the planned route, the method then 

distance traveled along the planned route. The vehicle is 30 includes planning a new route to the destination location, 

detected to has deviated from the planned route when the Planning the new route does not necessarily require further 

first estimated position and the second estimated position communication with the server. Planning the new route can 

differ by at least a tolerance distance. include determining the location of the vehicle and access- 

The method can feature detecting when the vehicle is at ^ ing a map database stored in the vehicle, 

a first point on the planned route, such as a maneuver point, The method can also include establishing a wireless 

and estimating the distance traveled along the path following communication channel with the server, transmitting a 

the first point. specification of the destination location over the wireless 

The method can also feature adjusting the tolerance communication channel, and then terminating the wireless 

distance, including reducing the tolerance distance when the 4Q communication channel after receiving the planned route, 

vehicle is detected to be at the first point on the planned Advantages of this method include providing a server 

route, and increasing the tolerance distance as the vehicle based route planning service to a vehicle, without requiring 

travels along the path following the first point. ongoing communication with the server to carry out guid- 

In general, in another aspect, the invention is a method for ance and route replanning functions, 

providing guidance instructions to a vehicle operator fol- 45 In general, in another aspect, the invention is a method for 

lowing a planned route that includes a sequence of maneuver collecting traffic information. The method includes tracking 

points. The method includes detecting when the vehicle is at the location of a vehicle, including detecting when the 

a first maneuver point, and tracking the distance traveled by vehicle traverses each of a plurality of segments of a road 

the vehicle from the first maneuver point along the planned network. For each detected segment, the method includes 

route. When the tracked distance is within a predetermined 50 logging traffic-related data, including logging data related to 

notification distance of the distance between the first maneu- the vehicle's speed on the detected segment. The method 

ver point and a subsequent maneuver point along the then includes transmitting the logged data to a server 

planned route the operator is notified of the subsequent The method can feature receiving a command from the 

maneuver, server to enable logging of the traffic-related data at a 

In general, in another aspect, the invention is a method for 55 vehicle. The method can also feature receiving at a vehicle 

specifying a location in a vehicle navigation system. The a request to transmit the logged data to the server, 

method features providing an in-vehicle map database to an In general, in another aspect, the invention is a method for 

in-vehicle system. The in-vehicle database includes data collecting traffic information. The method includes tracking 

related to valid location specifications for accessing a server the location of a vehicle, including detecting when the 

map database at a server system. The method also features 60 vehicle traverses each of a set of segments of a road network, 

accepting a location specification, for instance, for an opera- For each detected segment, the method features comparing 

tor using a user interface in the vehicle. The system validates the vehicle's speed on the segment to a stored speed for that 

the location specification using the in-vehicle map database segment, and if the vehicle's speed on the segment deviates 

and then transmits the validated location specification to the from the stored speed, transmitting a traffic notification 

server system. 65 identifying that segment to a server. 

The method can also feature providing the server map In general, in another aspect, the invention is a method for 

database to the server system and accessing the server map collecting traffic information. The method includes receiv- 



02/04/2004, EAST Version: 1.4.1 



US 6,639,550 B2 



10 



20 



ing traffic related data from a set of vehicles and updating a 
traffic database using the received traffic related data. Updat- 
ing the database includes updating speed information asso- 
ciated with multiple road segments in a road network. The 
method also features planning a route through the road 
network from a starting to a destination location using the 
speed information associated with the road segments. 

The method can also feature enabling a subset of an 
available set of probe vehicles to provide the traffic related 
data, and can, in addition, feature determining a part of the 
traffic database to target for updating, for instance, according 
to a the part of the database corresponding to a geographic 
area. Enabling the subset of probe vehicles then includes 
enabling probe vehicles according to the part of the database 
that is targeted. 

Id general, in another aspect, the invention is a method for 
specifying a destination to a vehicle navigation system. The 
method includes accessing a list of categories of 
destinations, and accepting a selection from the list of 
categories, for example, from an operator making the selec- 
tion on a in-vehicle user interface. The method includes 
transmitting the selection from the list of categories to a 
server system, and subsequently receiving a list of destina- 
tions from the selected category from the server system. The 
method then includes accepting a selection from the list of 25 
destinations and transmitting the selected destination to the 
server system. 

The method can also feature transmitting data related to 
the location of the vehicle to the server system. The received 3Q 
list of destinations then includes destinations that are in the 
vicinity of the vehicle. 

In general, in another aspect, the invention is a method for 
configuring a vehicle navigation system. The method 
includes providing a server map database to a server. The 
server map database includes data related to a plurality of 
road segments in a road network. The method also includes 
providing a vehicle map database to an in-vehicle system. 
The vehicle map database includes data related to a subset 
of the plurality of road segments in the server map database 
which satisfy a common criterion, for instance related to the 
road class of the road segments. 

In general, in another aspect, the invention is an in-vehicle 
map database. The database includes a first stored table and 
a second stored table. The first stored table includes multiple 
records each including a field containing a reference to a 
record containing a base name of a street in the second 
stored table, and a second field which identifies a prefix, a 
suffix, or a street type. The second stored table includes 
multiple records, each including a base name of a street 
stored in a compressed format. 

In general, in another aspect, the invention is method for 
transmitting a route to a vehicle navigation system. The 
route includes multiple intermediate points joined by road 
segments. The method includes transmitting a specification 
of the location of a first of the intermediate points, and 
transmitting a specification of a difference between the 
location of a second of the intermediate points and the first 
of the intermediate points. The specification of the difference 
can use fewer than an allocated number of bits. 

The method can also feature planning an initial route. The 
initial route includes an initial set of multiple intermediate 
points coupled by road segments. The planned route is 
formed from the initial route. For any of the road segments 
in the initial route for which the difference in locations of the 
intermediate points bounding that segment is greater than 
can be specified in the allocated number of bits, the method 
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includes inserting additional intermediate points on that road 
segment so that the differences between the locations of the 
adjacent intermediate points can each be specified in the 
allocated number of bits. 

In general, in another aspect, the invention is a vehicle 
navigation system. The system includes an onboard 
computer, including storage for a map database, a wireless 
communication system for passing data between the 
onboard computer and a remote server, an input/output 
device for providing a user interface between the onboard 
computer and an operator of the vehicle, and a vehicle 
sensor for providing motion-related signals to the onboard 
computer. The onboard computer is programmed to perform 
the functions of accepting a planned route from the server 
over the wireless communication system, maintaining a first 
location estimate of the vehicle using the motion-related 
signals from the vehicle sensor, and, using the planned route 
and the first location estimate, providing guidance instruc- 
tions to the operator through the input/output device. 

In general, in another aspect, the invention is a method for 
updating an in-vehicle navigation system. The method 
includes receiving a version number associated with infor- 
mation stored in the in-vehicle system. If the information 
stored in the in-vehicle system has a version number prior to 
the version of information a server, the method includes 
transmitting update information from the server to the 
in-vehicle system. The information stored in the in-vehicle 
system can include map data or computer instructions. 

The method can feature prioritizing the update 
information, for instance, according to the geographic area 
represented by the update information and transmitting the 
update information in order of the priority. 

In general, in another aspect, the invention is a vehicle 
information server system. The system includes a vehicle 
communication interface for providing wireless data com- 
munication between multiple vehicles and a set of informa- 
tion system. The set of information systems includes a 
navigation system for accepting route planning request from 
the vehicles and providing planned routes through the com- 
munication interface, and a communication system coupled 
to an external information system for delivering information 
from the external information system to the vehicles. 

In general, in another aspect, the invention is a method for 
providing traffic related information to a user. The method 
features accepting from the user a specification of a path 
made up of one or more road segments in a road network and 
receiving traffic data related to road segments in the road 
network. If the received traffic data indicates an exceptional 
traffic condition on the specified path, the user is notified of 
the traffic condition. 

Other features and advantages of the invention will be 
apparent from the following description, and from the 
claims. 

DESCRIPTION OF DRAWINGS 
FIG. 1 is a block diagram of a vehicle navigation system; 
FIG. 2 is a block diagram of in-vehicle components of the 
system; 

FIGS. 2A-C show an integrated input/output device; 

FIG. 3 is a block diagram including components of a 
server system; 

FIGS. 4A-B show an in-vehicle system software archi- 
tecture; 

FIG. 5 is a block diagram of a server system software 
architecture; 
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FIG. 6 is a schematic map showing the road network in an 106 provides an instruction to make a turn at an upcoming 

exemplary region; intersection while the vehicle is approaching the intersec- 

HG. 7 is a graph representation of the road network in the Also, in-vehicle system 105 typically determines when 

exemplary region* ^ °P erator has made an error and the vehicle is off a 

FIG. 8 illustrates an exemplary planned route that is 5 jj™ ed ro " te - ' f ,he whicle = |°. ff route - u - venicle s y stem 

downloaded from a server system to a vehicle; 105 provides the operator with instructions to continue to 

, .-, guide the vehicle to the destination despite the error. 

FIG. 9 is an exemplary spot map that is downloaded from Servef syslem n$ provides various lo m _ ve hicle 

a server system to a vehicle; system 105> m a u c]knl ^ saver arrangement in which 

FIG. 10 is a main roads map that is preloaded in a vehicle; 10 in-vehicle systems 105 request services from server system 

FIG. U shows data structures of an in-vehicle database; 125. For instance, a route planning function is performed by 

FIG. 12 shows the structure of text tables in the in-vehicle «*ver system 125 at the request of in-vehicle system 105 

database; while route guidance functions are performed by in-vehicle 

FIG. 13A shows a representative link of a main roads system 105. 

network; 15 ^jg^ghyk sA&eja& AOS are coupled to,sery.er.svstem.l25_ 

. * , . , , . by wireless communication lin ks., In particular, in-vehicle 

FIG. 13B shows data structures of an in-vehicle database -^yaeSFlBT™ server system 125 

encoding a mam roads network; ovef ^ paths u0 ^ modulaled data sigQals thal are 

FIG. 14 shows elements of an in-vehicle database which passed over a standard analogcellular telephone system (i.e., 

encode Points of Interest information; 2 o using the Advanced Mobile Phone Service (AMPS) 

FIG. 15 A is a pseudocode listing of an in-vehicle route standard). An in-vehicle system 105 typically operates in an 

planning procedure; autonomous mode after an initial exchange with server 

FIG. 15B is a pseudocode listing of a server route system 125. During the initial exchange, a starting location 

planning procedure; ( or other location- related data), speed and heading, and a 

FIG. 16 is a pseudocode listing of a startup maneuver 25 « ta jf« d destination are uploaded from the in-vehicle system 

procedure* to server system and then a planned route is downloaded 

' . . . . , „ . from the server system to the in-vehicle system. After 

FIG. 17 B a pseudocode listing of a route following pi aaned route information is downloaded to the vehicle from 

proc ure, ^ e server svstem> fte in-vehicle system does not require 

FIG. 18 is a pseudocode listing of a route replannig 30 further interaction with the server system to operate in its 

procedure; autonomous route guidance mode. While in the autonomous 

FIG. 19 illustrates a extensible server architecture; route guidance mode the in-vehicle system can recover from 

FIGS. 20A-20C illustrate approaches to updating an an operator going off the planned route without necessarily 

in-vehicle system; requiring further communication with the server system. 

FIGS. 21A-21B illustrate additional information services 35 In-vehicle systems 105 receive signals from GPS satel- 

provided by a server system; and ute s 140 over radio frequency communication paths 112. 

FIG. 22 is a block diagram of an extensible server system. Server svstem 125 als0 receives signals from GPS satellites 

140 over radio frequency communication path 122. As is 

DESCRIPTION described more fully below (see Section 2.4), data derived 

1 Overview (FIGS. 1, 6-10) 40 from signals received by server system 125 from GPS 

1.1 Architecture (FIG. 1) satellites 140 is used at times by both server system 125 and 

Referring to FIG. 1, a vehicle information system pro- in-vehicle systems 105 to improve the location estimates of 

vides services, including a route planning and guidance (i.e., vehicles 100, for instance, using "differential" GPS calcu- 

a "navigation") service, to the operators of multiple vehicles lations. 

100, which are free to drive throughout a wide geographic 45 Referring still to FIG. 1, server system 125 relies on a map 

area. To provide these services to the operators of the provider 160, for instance, a vendor of map -related 

vehicles, the vehicle information system performs some information, to provide information related to the road 

functions in a server system 125 at a central i zed server 120 network, including the locations and types of road segments 

that is at a fixed location, and other functions in in-vehicle that interconnect to form the road network. Map provider 

systems 105 installed in each of the vehicles 100. The 50 160, or some other external information provider, also 

vehicle information system also includes a positioning sys- provides other map-related information such as the locations 

tem that provides a reference for estimating the locations of of typical points of interest such as city centers, restaurants, 

vehicles 100 in absolute terms (i.e., in terms of their latitudes and gas stations. 

and longitudes). In particular, Global Positioning System In some versions of the system, server system 125 also 
(GPS) satellites 140 provide signals that when received at 55 serves as a gateway to external information systems 130. 
the vehicles enable the in-vehicle systems to estimate their These external systems provide information used by server 
locations. system 125, or provide information that is passed directly to 
The navigation service of the vehicle information system in-vehicle systems 105. For instance, an external informa- 
as a whole, which are provided through a combination of tion system 130 can provide traffic-related information that 
functions that are performed by server system 125 and by an 60 is used by server system 125 to determine a fastest route 
in-vehicle system 105, enable an operator of a vehicle to from a starting to a destination location. In another instance, 
specify a desired destination, and then to be guided by the an external information system 130 can provide communi- 
system to that destination while driving the vehicle. cation services to vehicle operators, such as a paging ser- 
in-vehicle system 105 tracks (i.e., repeatedly estimates) the vice. 

position of the vehicle as it travels to the desired destination, 65 Alternative communication approaches between 

and provides instructions to the operator to guide the opera- in-vehicle systems 105 and server system 125 can be used, 

tor to the desired destination. For instance, in-vehicle system Use of standard analog cellular telephone links is useful due 
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to the broad geographic coverage in North America of the 
infrastructure needed to support such links. In other parts of 
the world, digital cellular telephone links may be more 
appropriate if the necessary infrastructure is available. Such 
a digital-based infrastructure is expected to be available in 5 
North America in the future. A satellite-based communica- 
tion system can alternatively be used to link the in-vehicle 
systems to the server system. Also, other wireless data 
communication systems can be equivalently used to couple 
in-vehicle systems 105 and server system 125. Such systems 10 
are currently being deployed in North America (e.g., 
ARDIS, RAM, CDPD, GSM), although the geographic 
coverage is not yet adequate to support this system and 
provide broad geographic availability to vehicle operators. 
Many wireless communication systems also include a "short 15 
message" capability with which short messages can be 
transferred. Such short message services can alternatively be 
used for some types of communication between the 
in-vehicle systems and the server system, for instance for 
notification of exception conditions. 20 

Also, alternative positioning systems can be used rather 
than relying on signals from GPS satellites 140. For 
instance, a roadside optical or radio frequency beacon sys- 
tems can be used to provide location information to vehicles. 
Such a roadside beacon system is not broadly available in 25 
North America. On the other hand, the GPS*based approach 
provides broad geographic coverage today. 

Centralized server 120 is "centralized" in that it provides 
services at one location for vehicles that are distributed 
throughout a geographic area. The centralized server's loca- 30 
tion does not have to be "central" or even located in the same 
geographic area as the vehicles it services. Also, although 
the system is described in terms of a single centralized server 
120, multiple servers can alternatively be used. When mul- 
tiple servers are used, in-vehicle systems 105 can be con- 35 
figured to access particular servers for all, or for particular 
types of, service requests. 
1.2 Operation (FIGS. 6-10) 

General operation of the navigation service of the vehicle 
information system can be understood with reference to 40 
FIGS. 6-10, which illustrate various representations of 
exemplary maps and routes that are used in the system. 
These drawings correspond to a common geographic area 
that is shown schematically in FIG. 6. The geographic area 
shown is only a very small portion of the area that is 45 
typically supported by the navigation service, which may be 
as large as the United States or multiple countries in Europe. 

Referring to FIG. 6, a map 600 is illustrated with three 
classes of roads shown in different line widths. In general, 
roads are classified according to their size or typical vehicle 50 
speed, for example, highways, limited access roads, main 
roads, and side streets. In FIG. 6, a highway 610 is shown 
as a thick line running along the vertical orientation of the 
drawing. A set of main roads 620, 622, 624, and 626, which 
is shown in medium thickness lines, form an intersecting 55 
network. Main roads 620 and 622 are connected to highway 
610 al two on-ramps, 612 and 614, respectively. A set of 
residential roads (side streets) 630-636 completes the road 
network. 

In this example, an operator and vehicle are initially at the 60 
point marked 'X* 690. The operator wants to get to a desired 
destination 692 that is not shown in the drawings, but that is 
best accessed by following highway 610 as indicated in the 
drawings. 

As the first step, the operator enters a specification of 65 
desired destination 692 into in-vehicle system 105. For 
instance, the operator enters the city, street, and street 



number of a destination address. The destination is validated 
by the in-vehicle system, for instance validating that the 
street address is in an allowable range for the specified 
street. 

After in-vehicle system 105 has accepted and validated 
the destination specification, it establishes a communication 
session with server system 125 over cellular telephone link 
110 and sends the destination specification to the server 
system. The in-vehicle system also sends information to the 
server system that allows the server system to determine the 
vehicle's starting location 690. For instance, the in-vehicle 
system sends the estimated latitude and longitude output 
obtained from a GPS receiver in the vehicle, or sends other 
raw output from its GPS receiver. 

Referring to FIG. 7, the server system includes a stored 
detailed representation of the road network 700. The net- 
work is represented as a graph with a set of nodes, indicated 
in the drawing by open circles, that are interconnected by 
finks (arcs) that correspond to road segments. Links in the 
graph have associated stored data which includes the class of 
the road represented by the finks. Each node in the graph has 
associated data including its latitude and longitude (or 
equivalently its relative location to another node that is at a 
known location), as well as other information, such as which 
turns from one link to another link joined at the node are 
valid. Many links are approximated by straight line seg- 
ments joining the nodes at each end of the link. Some links, 
such as the links joining nodes 733 and 735 or nodes 716 and 
725, represent curved road segments. To represent such 
curved road segments, links can include one or more "shape 
points," represented as hatched circles 780-785 in the draw- 
ing. Each shape point has location data associated with it. 
The segments between adjacent shape points, or between 
nodes and adjacent shape points, are approximated by 
straight line segments. 

Server system 125 uses the information provided by the 
in-vehicle system related to the location of the vehicle 690 
to determine the starting latitude and longitude of the 
vehicle. Based on the vehicle's latitude and longitude, 
speed, and heading, the server system finds the vehicle's 
starting link in its graph representation of road network 700. 
In this example, this first point on the road network is on the 
link joining nodes 753 and 763. 

The server system next computes a best path to destina- 
tion 692. "Best" can be based on a variety of criteria such as 
the smallest total distance, or the shortest expected travel 
time using information related to the expected speed of 
travel along links of the roadway graph. In this example, this 
planned route is illustrated by the dotted fine 792. Referring 
back to FIG. 6, this planned route has the vehicle starting on 
residential road 635 and first making a left on residential 
road 632. The vehicle then is to make a right turn onto main 
road 628, and a right onto main road 620. Main road 620 
merges onto highway 610. The vehicle then is to continue 
along highway 610 toward destination 692. 

Referring to FIG. 8, planned route 800 is downloaded 
from the server system to the in-vehicle system in the form 
of a sequence of links joined by nodes. Each node along the 
route (other than necessarily the start node) corresponds to 
a node in the server's road network 700 (FIG. 7). Nodes 
along planned route 800 correspond to "maneuvers" that 
must be carried out by the operator. For example, the 
maneuver at node 790 is "turn left onto road 635" (See FIG. 
6). Each link along the route can have one or more "way 
points." Way points correspond to shape points in the 
server's road network 700, or to nodes which are intersec- 
tions at which the operator does not have to make a 
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maneuver, that is, nodes of the server's road network 700 at includes only main and larger roadways (i.e., it does not 

which the operator simply continues without turning or include residential roads). A portion of the main roads 

making some other maneuver. In FIG. 8, nodes 733, 780, network 1000 is shown in FIG. 10. Main roads network 1000 

and 781 arc way points on the link joining maneuver points has a similar form as the server's road network 700 shown 

732 and 735. 5 in FIG. 7, except that fewer links are included. For reference, 

In principle, if the operator could always be expected to the planned route 792 is illustrated by a dotted line, 

follow directions exactly, then the operator will drive to the While traveling toward the destination, the in-vehicle 

desired destination. However, various factors may result in system tracks an estimated location of the vehicle. If the 

the operator not reaching the desired destination without operator does not properly follow the directions, the 

further planning. These factors include: 1(J in-vehicle system will typically detect when the vehicle has 

Inaccuracy in the estimate of the vehicle's initial location, diverged loo far from the planned route. When it detects that 

for example due to closely spaced side streets, the vehicle is off-route, it plans a corrected route based on 

The operator's inability to follow directions, particularly the main roads map shown in FIG. 10 which get the vehicle 

during the initial startup portion of a route where the back onto the originally planned route, 

directions may be complicated, 15 Referring back to FIG. 6, in this example, the operator 

Errors in the system's map of the road network, for fails to make the right turn from main road 628 onto main 

instance, due to unexpected road construction, and road 620, continuing instead on main road 628. Referring 

Inaccuracy in estimating the distance traveled by the back t0 nG - 10 > ^ ^-vehicle system determines that the 

vehicle. vehicle is off-route at a point 1010, which corresponds to a 

In order to account for errors associated with the startup 20 P oim 0D a main road segment between nodes 732 and 722 

portion of the route, the server system downloads to the when it should have been at a point on the link joinmgpomts 

in-vehicle system a detailed map 900, known as a "spot 732 and 735 - Usin g its main road network 1000 > the 

map," around initial location 690. Referring to FIG. 9, map in-vehicle system plans a corrected route indicated by the 

information related to nodes and links in the vicinity of dashed Une 1012 - ^ ^-planned route joins the originally 

starting location 690 are downloaded. Spot map 900 has as 25 Panned route at point 725. Note that in replanning a route 

high a level of detail as does the server's road network 700, after an off-route condition occurs, the in-vehicle system 

but is limited geographically, for instance including all does no1 necessarily have to contact the server system, 

nodes within two links of the starting location. reIvia S instead 0D its main roads network 1000. 

The server system can also download a spot map around 706 ^-vehicle system therefore uses a combination of 

one, or more, maneuver points, or around the destination. 30 main roads network 1000 that is preloaded into the vehicle 

For instance, if a maneuver is particularly complex, the and spot maps 900 that are downloaded to the vehicle along 

server system would download a spot map around that with planned route 800 to replan the route when the vehicle 

maneuver point. ^ detected to not be following the planned route. 

After planned route 800 and spot map 900 are down- In an alternative version of the system, spot maps 900 can 

loaded to the vehicle, communication between in-vehicle 35 be ^ 6 t0 augment main roads network 1000 to re-plan the 

system 105 and server system 125 is typically completed. At route * the operator fails to follow the planned route during 

this point, the operator can preview the route, or can start ^ imtial Po ruon of the trip. 

traveling to the destination. The operator can also start Id tne system operation described above, a vehicle opera- 
traveling before the planned route is downloaded. The tor receives instructions in the form of 
in-vehicle system begins providing initial guidance com- 40 Graphically presented maneuver instructions, 
mands and displaying the spot map around the starting Aural maneuver instructions, and 
location to the operator as soon as it is downloaded without Spot map based instructions. 

necessarily waiting for the complete route to be down- Alternative versions of the system use subsets of these 

loaded. forms of instructions. For instance, a version of the system 

While traveling to the destination, the in-vehicle system 45 can use aural instructions alone. Another version of the 

attempts to track the location of the vehicle. As the system can use graphically presented maneuver instructions 

in-vehicle system determines that the vehicle is approaching without any map based or aural instructions. Other combi- 

each maneuver point, it provides aural and graphical instruc- nations or instruction modes can be used as well, 

tioos to the operator regarding the action to take at that Furthermore, alternative versions of the system can give the 

maneuver point. If a spot map has been downloaded for the 50 vehicle operator control over which instruction modes are 

maneuver, the in-vehicle system displays the spot map in used, for instance, allowing the operator to switch between 

addition to, or instead of, the graphical instructions. map based and graphical instruction based modes. 

During the initial portion of the trip or near a maneuver 2 Hardware and Software Architecture (FIGS, 2-5) 
for which the server system has provided a spot map, while 2.1 In- Vehicle System Components (FIG. 2) 
the vehicle is in the region of a spot map 900, the spot map 55 Referring to FIG. 2, each in-vehicle system 105 includes 
is used by the in-vehicle system to guide the operator onto an onboard computer 210 which is used to coordinate the 
the planned route. In particular, the in-vehicle system dis- operation of other components, including sensors 230, 
plays the spot map and the initial portion of the planned which provide information related to the motion of the 
route to the operator. In addition, the in-vehicle system vehicle, input/output (I/O) devices 240, which provide an 
displays the tracked location of the vehicle in conjunction 60 interface between the operator of the vehicle and the navi- 
with the spot map. This allows the operator to recover from gation system, and communication system 250, which pro- 
errors during the initial portion of the trip by seeing that the vides communication links from GPS satellites 140 and to 
tracked location is not following the planned route, and and from server system 125. Onboard computer 210 is also 
using the roads shown on the spot map to determine what coupled to vehicle systems 270, which include door locking 
turns to make to get back to the planned route. 65 system 272 and airbag system 274. 

The in-vehicle system also has a preloaded main roads Onboard computer 210 has limited storage and processing 

network 1000, which is a stored version of the map that capabilities. In this version of the in vehicle system, onboard 
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computer 210 includes a processor 212 coupled to other sentations of commands. Referring to FIGS. 2B-C, display 

components of the onboard computer over a data bus 214. 242 is used at times to provide visual feedback to the 

The other components includes dynamic random access operator when inputting information. FIG. 2B illustrates 

memory (DRAM) 220, which provides 2 MB of working selection from a list and FIG. 2C illustrates spelled input in 

storage for processor 212, erasable programmable read-only 5 which the operator uses the rotary switch to select letters to 

memory (EPROM) 218, which provides 4 MB of non- spell an input word. 

volatile storage, and universal asynchronous receiver- Referring back to FIG. 2, I/O devices 240 also include a 

transmitter (UART) 216, which provides serial communi- voice output device 246. Voice output device 246 provides 

cation capabilities to other system components. Alternative audio output of speech commands that are stored or formed 

hardware configurations, for instance, with more or less 10 on onboard computer, for example, using compressed or 

memory, can be used. concatenated waveforms or a speech synthesizer. 

Processor 212 is also coupled to a static storage 222 which I/O devices 240 can be dedicated to onboard computer 
is a non- volatile storage used to store code and data for 210, or can alternatively be part of another vehicle compo- 
operation of the system. In particular, as is described further nent such as a radio. In the latter case, display 242 and input 
below, static storage 222 is used to store map-related is device 244 are the display and input buttons of the other 
information, such as main roads network 1000 (FIG. 10), component, respectively. Many audio components include 
which is used during route planning and guidance proce- standard control interfaces, such as the ACP (Audio Control 
durcs executed on onboard computer 210. Static storage 222 Protocol) interface used in vehicles manufactured by the 
is a removable 40 MB flash memory system which emulates Ford Motor Company. Id such a case, onboard computer 210 
a disk storage device. Alternative static storage devices can 20 can communicate with the audio component using a stan- 
ce used, including removable and non-removable disk stor- dard communication interface. Voice output can be provided 
age devices and semiconductor memories. to the operator by passing it through the audio system, or 

Sensors 230 include a velocity sensor 232 which provides alternatively, onboard computer 210 can mule or attenuate 

a velocity signal to onboard computer 210. The velocity the audio system while voice output is provided through a 

signal encodes the distance traveled by the vehicle by 25 dedicated audio path. 

providing a constant number of pulses per revolution of the Referring still to FIG. 2, communication system 250 
output of the vehicle's transmission, and which therefore includes a GPS receiver 252 coupled to a GPS antenna 253 
provides a relative constant number of pulses per mile for receiving signals from GPS satellites 140. GPS receiver 
traveled. Sensors 230 also includes a magnetic compass 234 252 repeatedly provides location-related information to 
which provides a signal to onboard computer 210 encoding 30 onboard computer 210, for example, at one-second intervals, 
the orientation of the vehicle. Alternative versions of the The location related information can be an estimated 
system do not necessarily include magnetic compass 234, location, in terms of latitude and longitude, or other raw 
relying only on the velocity signal. Also, alternative versions measurements that can be used to compute an estimated 
may include other sensors of the state of the vehicle, location. GPS receiver 252 can also receive correction data 
including a gyroscope or accelerometers for determining the 35 from onboard computer 210, which it uses to compute 
rate of rotation of the vehicle, or a differential velocity increased accuracy location estimates from its raw measure- 
sensor, which provides the relative speed of the wheels on ments. As is described further below, the correction data can 
either side of the vehicle thereby encoding a turning radius be provided by server system 125 and is used at times to 
of the vehicle as it goes through a turn. increase the accuracy of the location information provided 

I/O devices 240 includes a display 242, In versions of the 40 by GPS receiver 252. 
in-vebicle system in which only graphical commands are Communication system 250 also includes a cellular trans- 
displayed, display 242 is a small (e.g., 4-5 lines of text high, ceiver 254 coupled to a cellular telephone antenna 255. 
64x240 pixels) monochrome liquid crystal display (LCD) Cellular transceiver 254 provides voice and data communi- 
which is used to provide text and schematic image instruc- cation capabilities to the vehicle. A modem 256 is coupled 
lions to the operator of the vehicle. In versions of the 45 between onboard computer 210 and cellular transceiver 254. 
in-vehicle system in which spot maps are displayed to the Data sent to and received from server system 125 over a 
operator, display 242 is 4 to 5 inch diagonal display with cellular telephone line passes through modem 256. Cellular 
approximately 200x200 pixels, which is large enough and transceiver 254 is also coupled to a handset 260. The 
has a high enough resolution to provide a detailed map operator can place standard telephone calls using handset 
display to the operator that can be used to provide map- 50 260 when cellular transceiver 254 is not being used to 
based directions to the operator. Also, io alternative versions communicate with server system 125. 
of the system, visual feedback is not necessarily used, 2.2 Server System Components (FIG. 3) 
relying instead solely on audio instructions from the system Referring to FIG. 3, server system 125 includes a server 
to the operator. computer 310, which communicates with in-vehicle systems 

I/O devices 240 also includes an input device 244. Input 55 105. Server system 125 includes a telephone interface 320 

device 244 includes multiple push buttons associated with for receiving and placing telephone calls to establish data 

display 242. The operator uses these buttons to select communication sessions with individual in-vehicle systems 

alternatives shown on display 242, or to scroll the list of 105. 

displayed alternatives. Alternative versions of the system An in-vehicle system 105 initiates a communication ses- 

can include an alphanumeric keyboard coupled to the 60 sion with server system 125 by placing a cellular telephone 

onboard computer. call to a telephone number associated with the server system. 

Referring to FIGS. 2A-C, an integrated I/O device 241 The call is routed through a cellular telephone network 350 

includes display 242 and a set of four rocker switches that to public switched telephone network (PSTN) 340 and then 

are part of input device 244. One rocker switch is dedicated to telephone interface 320. Telephone interface 320 answers 

to "menu" and "cancel" inputs while the other three are 65 the call. Telephone interface includes a modem function 

reconflgurable. Referring to FIG. 2A, display 242 is at times which is used to establish a data connection with modem 256 

used to display both text commands and graphical repre- (FIG. 2) in the calling vehicle. In alternative versions of the 
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system, telephone interface 320 may be coupled directly to 
cellular telephone network 350. Also, the data signal may be 
demodulated prior to reaching the server system, for 
example, in the telephone network itself. 

The server system can similarly establish a data commu- 
nication session with a particular vehicle by placing a 
telephone call to the telephone number associated with that 
vehicle. Cellular transceiver 254 (FIG. 2) determines 
whether the inbound call is a data call from the server system 
or a voice call intended for voice communication with the 
operator of the vehicle. A data call is connected to modem 
256 (FIG. 2) providing a data connection between telephone 
interface 320 and modem 256. 

Server system 125 also includes a GPS receiver 325. GPS 
receiver 325 receives signals from GPS satellites 140. Server 
system 125, which is at the known location of centralized 
server 120, does not rely on GPS receiver 325 to determine 
its location. Rather, server computer 310 provides its known 
location (i.e., latitude and longitude) to GPS receiver 325, 
Using the satellite signals and the known location of the 
server, GPS receiver 325 provides in return GPS correction 
data, for instance, "differential" pseudorange correction data 
provided according to the Radio Technical Commission for 
Maritime Services (RTCM) standard RTCM SC-104. This 
correction data is used to improve the locations estimates of 
vehicles 100, as is described more fully in Section 2.4. 

Server computer 310 includes a processor 312, working 
memory 314, and static storage 316. Static memory 316 
includes storage for map-related information that is used by 
the server system in computing routes. 

Server computer is coupled to external information sys- 
tems 130. For instance, external information systems can be 
other computers coupled to server system 125 over a data 
network 330, such as the Internet. 

Server system 125 receives map information from map 
provider 160 on a removable computer medium 360, such as 
a optical disk (e.g., CD-ROM). Server computer 310 reads 
this map data and stores a processed form of the map 
information in static memory 316 for further use. 
Alternatively, map provider 160 can provide the map infor- 
mation to the server system in some other way, for example 
by passing it to the server system over data network 330. 
2.3 Map Database 

The in-vehicle and server systems make use of data 
derived from map information furnished by map provider 
160 on computer medium 360 (FIG. 3). The raw map 
information furnished by map provider 160 includes various 
types of information related to the road network for a 
particular geographic region, such as a portion of the United 
States. Within this region, the information includes a repre- 
sentation of the road network as a graph as illustrated in FIG. 
7. Links in the graph correspond to segments of the road 
network, for example, a segment of a street between two 
intersections. Nodes in the graph correspond to intersections 
or other points at which two or more links join. Nodes that 
couple only two links are used, for example, as "shape 
points" when a single roadway makes a turn. This allows 
roadway to be well approximated by sequences of straight 
segments. 

The map information includes the locations of nodes in 
the graph, in terms equivalent to their latitude and longitude. 
The map information also includes link information, includ- 
ing associations of street names and links, and ranges of 
street numbers on links. Links are also categorized accord- 
ing to their size ranging from small residential streets to 
interstate highways. 

An example of a map provider for this system is Navi- 
gational Technologies Inc. (NavTech) of Rosemont, III. The 
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map information is provided in one of a number of inter- 
change formats, such as in the Geographic Data File (GDF) 
format, an international standard format. A map in GDF 
format includes a data structure which associates links and 

5 nodes and their attributes, and relationships between nodes 
and links in the graph. NavTech provides maps in which 
road links are categorized by classes from 0 to 4, with 0 for 
residential (side) streets, 1 for main streets, 2 for arterial 
roads, 3 for freeways, and 4 for interstate highways. 

10 In alternative versions of the system, other forms of map 
information that can be converted to a link and node 
representation of a road network can alternatively be used. 
2.4 GPS and DGPS Correction 
As outlined above, both the in-vehicle and server systems 

15 include GPS receivers. GPS positioning uses the ranges to 
multiple satellites that are in precisely known orbits around 
the earth. A constellation of approximately 24 satellites is in 
such known earth orbits. A receiver at any point on or near 
the surface of the earth is typically in range of a subset of 

20 three or more of the satellites. A GPS receiver determines an 
estimate of its distance or range (a pseudorange 
measurement) to each of the subset of in-range satellites. It 
then computes its three-dimensional coordinates with refer- 
ence to the known coordinates of each of the subset of 

25 satellites to which it determined pseudorange measurements. 
Based on straightforward geometric consideration (i.e., 
intersections of spheres) four pseudorange measurements 
are sufficient to uniquely determine the coordinates of the 
receiver. Three measurements are sufficient to determine that 

30 the receiver is at one of two possible points, and typically, 
only one of the points is reasonable (e.g., it is on the surface 
of the earth rather than in outer space). Using three pseu- 
dorange measurements, a GPS receiver can determine a 
two-dimensional location on the surface of the earth with an 

35 accuracy of approximately 100 meters. 

The pseudorange measurements are not, however, com- 
pletely accurate measurements of the distance from the 
receiver to the satellites due to several factors. First, signal 
propagation speed from a satellite to a GPS receiver can vary 

40 due to variations in atmospheric conditions. Also, the trans- 
mitted signals are intentionally manipulated by introducing 
varying time delay at the transmitter in order to limit the 
accuracy of location estimates based solely on the pseudo- 
range measurements at the receiver. 

45 As a method of overcoming the inaccuracies in the 
pseudorange measurements, differential GPS (DGPS) is 
used. Differential GPS is based on receiving signals from 
GPS satellites at a receiver that is at a known location. The 
difference between a pseudorange measurement from a 

so satellite to that receiver and a computed distance between 
the location of the satellite and the location of the receiver 
is a pseudorange correction term for that satellite. Separate 
pseudorange correction terms are computed for each satel- 
lite. To the extent that propagation is slowly varying and the 

55 intentionally introduced delays are also slowly varying, a 
pseudorange correction term for a satellite can be used to 
correct further pseudorange measurements from that satel- 
lite for a short period of time relative to the rates of variation, 
for example for one minute. Also, to the extent that varia- 

60 tions in propagation speed are not geographically local, a 
pseudorange correction term can be applied at a GPS 
receiver that is at a different location than the GPS receiver 
at which the correction term was computed. 

In the vehicle information system, three approaches to 

65 differential GPS correction are used. A first approach is 
generally known as "inverted DGPS." In this approach, an 
in-vehicle system sends the pseudorange measurements, or 
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other raw GPS data that is related to the pseudorange includes tables that specify types of points of interest, and 

measurements, that it obtains from its GPS receiver to the the points of interest of a particular type near a vehicle's 

server system over 'the cellular telephone link. The server location or in a particular city. 

system applies the differential correction terms it previously For the guidance phase, database 432 includes additional 

obtained from its own GPS receiver to the received pseu- 5 tables that the in-vehicle system uses to plan a route from a 

dorange measurements it receives from the in-vehicle sys- determined location (latitude and longitude) to a desired 

tem and the server system calculates a corrected location for destination or an intermediate point on a previously planned 

the vehicle. route. For instance, the main roads network 1000 (FIG. 10) 

In a second approach to GPS location estimation, the is stored in data tables in in-vehicle database 432. 

server system transmits pseudorange correction data to an 10 Referring to FIG. 11, an AddressCilyState table 1U0 in 

in-vehicle system. The in-vehicle system provides the in-vehicle database 432 includes a series of records that 

received correction data to its GPS receiver which then associate (Country, State, City) combinations with a series 

outputs improved location estimates based on its raw pseu- of (Street, Address Range) combinations. A typical record 

dorange measurements and the pseudorange correction data. 1112 in AddressCilyState table 1110 includes a Country field 

A third way that differential GPS is used in the system is 15 1114 that references the name of a country in a Country table 

for an in-vehicle system to determine its own pseudorange 1120. Country table 1120 holds the text representations of 

correction data based on its own location estimate. For the names of known countries, such as "United States" or 

instance, when an in-vehicle system detects that the vehicle "Canada." Record 1112 also has a CityState field 1116 which 

is at a known maneuver point along a planned route, it is a reference to a CityState table 1130 that is used to 

computes the pseudorange correction data based on the 20 determine the text representation of a city and state in the 

downloaded location of the maneuver point. The differential country referenced by Country field 1114. Record 1112 also 

correction data is then used for a period of time after the includes an AddressStreet field 1118 that references the first 

maneuver point is passed. of a range of records 1158 in an AddressStreet table 1150. 

An alternative mode of correction of GPS location esti- Directly after record 1112 in AddressCityState table 1110, a 

mates computed by the in-vehicle system uses correction 25 record 1113 includes an AddressStreet field 1119 that refer- 

data in terms of differences in latitude and longitude rather ences the next record 1153 after range 1158, thereby defining 

than differences in pseudorange measurements. For the records in range 1158. 

instance, the server system can provide GPS correction data Each record in AddressStreet table 1150 is associated with 

that includes an offset in latitude and in longitude that the a combination of a complete street name, and a range of 

in-vehicle system adds to the latitude and longitude location 30 valid street numbers for that street name. Multiple records in 

estimates output from its GPS receiver. If this type of GPS AddressStreet table 1150 can refer to the same street name 

correction is used, the in-vehicle GPS receiver does not have in order to build up an entire range of valid street numbers, 

to have a differential GPS capability since the location A typical record 1152 in AddressStreet table 1150 includes 

correction is performed on the output of the GPS receiver, a Streetname field 1154 and an AddressRange field 1156. 

rather than as part of the process of computing a location 35 Streetname field 1154 references a record in a StreetRecord 

estimate in the GPS receiver. table 1160 that is used to form the text representation of the 

25 In- Vehicle Software Components (FIGS. 4A-B) street name. AddressRange field 1156 references a record 

Referring to FIGS. 4A-B, software components of 1182 in AddressRange table 1180 that includes entries for 

in-vehicle system 105 which execute on onboard computer the lowest 1184 and highest 1186 numerical values in a valid 

210 (FIG. 2) include relatively static data stored in static 40 range of the street numbers for the associate street, 

storage 222, and code stored in working storage 410, which StreetRecord table 1160 is used to form completely speci- 

is made up of some combination of DRAM 220 and EPROM fied street names in terms of base street names, optional 

218 shown in FIG. 2. prefixes and suffixes, and street types. For instance, "North 

Static data includes in-vehicle database 432 and software Main Blvd" is represented by the base street name "Main," 

436. Code in working storage 410 includes a navigation 45 the prefix/suffix combination "North/-" and the street type 

application 412, a communication interface 414, and a "Blvd." A typical record 1162 in StreetRecord table 1160 

vehicle interface 416. Communication interface 414 pro- includes a StreetName field 1164 that references the text 

vides an interface between navigation application 412 and form of the base street name stored in a StreetName table 

GPS receiver 252 and cellular transceiver 254. Vehicle 1170, and an AfExType field 1166 that includes a represen- 

interface 416 provides an interface between navigation 50 tation of the prefix/sufHx combination as an index to the 

application 412 and sensors 230, vehicle systems 270, and predetermined set of prefix/suffix combinations and a text 

I/O devices 240. representation of the street type. 

2.5.1 In-Vehicle Database 432 (FIGS. 11-14) Referring back to record 1112 in AddressCityState table 

In-vehicle database 432 is used by in-vehicle system 105 1110, CityState field 1116 references a record 1132 in 

for two principle functions. First, in-vehicle system 105 uses 55 CityState table 1130. Record 1132 includes a City field 1134 

in-vehicle database 432 in the destination specification that encodes the text representation of the name of the city, 

phase in which the database is used to determine alternatives and a State field 1136 that references a record 1142 in a State 

to present to the operator, and to validate inputs from the table 1140 that encodes the name of the state, 

operator. Second, in-vehicle system 105 uses in-vehicle Several tables shown in FIG. 11 store lists of text names, 

database 432 during the guidance phase when the in-vehicle 60 These include Country table 1120, StreetName table 1170, 

system detects that the vehicle is off route and it must plan State table 1140, and CityState table 1130. In FIG. 11, 

a new route. references to records are shown as providing a direct access 

For the destination entry phase, database 432 includes to the stored text representations. Referring to FIG. 12, a 

tables that are used by the in-vehicle system to determine the representative text table 1200 includes an index 1210 and a 

names of known cities, the street names of streets in those 65 compressed text region 1220. A reference to a particular 

cities (including residential, or side, streets), and the valid record is used as an offset to a record 1212 in index 1210. 

street address numbers on those streets. The database also Record 1212 includes a starting field 1214 and a length field 
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1216. Compressed text 1220 includes the concatenation of 
all the text records, encoded as a sequence of 6-bit character 
representation. Starting field 1214 is the index of the starting 
6-bit character of the record. In order for a procedure 
executing on onboard computer 210 to access the text string, 5 
the procedure first converts the index to the address of the 
starting 8-bit byte of storage, and then it unpacks the 6-bit 
character representation to form a standard S-bit character 
representation of the record. 

Referring to FIG. 14, an additional set of tables supports 10 
entry of a destination in terms of a "point of interest" (POI). 
Points of interest are divided by type, such as "restaurants," 
"ATM machines," and "gas stations." A POiType table 1410 
includes a sequence of records. A typical record 1412 in 
POIType table 1410 includes a Type field 1414 that refer- is 
ences a record 1422 in a POIiypes table 1420. Record 1422 
is a text representation of the type of POI. 

Record 1412 of POIType table 1410 includes an Offset 
field 1416 that references a first record 1432 of a range 1444 
of records in a POINameCity table 1430 An Offset field 20 
1417 of a record 1413 that immediately follows record 1412 
in POIType table 1410 references a record 1446 in POINa- 
meCity table 1430 that immediately follows range 1444 of 
records in POIType table 1410. 

Record 1432 in POINameCity table 1430 includes a 25 
Country field 1434, which references a record in Country 
table 1120 (FIG. 11), a CityState field 1436, which refer- 
ences a record in CityState table 1130, a POIName filed 
1438, and an Offset field 1440, which references a record 
1452 in a POIList table 1450 which is the first record in a 30 
range 1464 of records in POIList table 1450 associated with 
record 1432. An Onset field 1440 of a record 1433 that 
immediately follows record 1432 in POINameCity table 
1430 references a record 1466 that immediately follows 
range 1464 in POIList table 1450. 35 

Record 1452 in POIList table 1450 includes a StreetName 
field 1454, which references a record in StreetRecord table 
1160, an Address field 1456 that encodes the street number 
associated with the address of the point of interest, a 
PhoneNumber field 1458 which encodes the telephone num- 40 
ber of the point of interest, and a Latitude/Longitude field 
1460 which encodes the latitude and longitude of the point 
of interest. 

Additional tables are included in in-vebicle database 432 
to support other forms of destination specification. In ver- 45 
sions of the system that support destination specification in 
terms of a "Yellow Pages" (telephone directory) category, 
in -vehicle database 432 includes a text table of "Yellow 
Pages" categories. In versions of system that support desti- 
nation specification in terms of a pair of intersecting roads, 50 
a table of valid cross-street combinations is included in 
in-vehicle database 432. If a table of cross-street combina- 
tions is included, the table can alternatively include only 
intersections of main streets, or additionally include inter- 
sections of main streets and smaller residential streets, or 55 
even intersections of pairs of residential streets, if sufficient 
storage is available in the in-vehicle system. 

Additional tables in in-vehicle database 432 (FIG. 4) are 
used during the guidance phase when the vehicle is deter- 
mined to be off route. In particular, these tables encode main 60 
roads network 1000 (FIG. 10). Referring to FIG. 13A, a 
representative link of main roads network 1000 joins a node 
i 1301 and a nodej 1302. Link c 1307 joins nodes i 1301 and 
j 1302. Link c 1307 includes two shape points 1303 and 
1303. Node i 1301 is also connected to links a 1305 and b 65 
1306 and node j 1302 is also connected to links d 1308 and 
e 1309. 



Referring to FIG. 13B, several tables are used to represent 
the main roads network 1000. Records in these tables related 
to the representative link shown in FIG. 13A are illustrated 
in FIG. 13B. A MasterNode table 1310 includes one logi- 
cally variable length record for each node in the network. A 
record 1312 which is associated with node i 1301 includes 
a Latitude/Longitude field 1314 that encodes the location of 
node i 1301. Record 1312 also includes a set of link fields 
1316, one for each of the links joined at node i 1301. Each 
link field 1316 includes information related to allowable 
turns from that link onto other finks at that node, and 
includes a reference to a record in a LinkSegments table 
1330 associated with that fink. For instance, the link field 
1316 associated with link c 1307 references record 1332 in 
LinkSegments table 1330. 

Record 1332 in LinkSegments table 1330 includes a 
StreetName field 1334, which references a record in Stree- 
tRecord table 1160, and a reference node field 1336 and a 
non-reference node field 1338 which reference records 1312 
and 1318 in MasterNode table 1310, respectively Record 
1332 also includes a ShapePointlnfo field 1340 which 
references a record 1352 in a LinkShapePoint table 1350. 
The record referenced by ShapePointlnfo field 1340 
includes information related to the shape points on the link, 
as well as information related to signs on the link. Record 
1332 also includes a Class field 1342, which encodes the 
road class of the link, and an AddressRanges field 1344, 
which references two records in AddressRange table 1180, 
one for each side of the road. 

Record 1352 in LinkShapePoint table 1350 includes a 
NumberShape Points field 1354 and a NumberSigns field 
1356. For each shape point, record 1352 includes an encod- 
ing of the change in latitude and longitude from the previous 
shape point, or from the reference node for the first shape 
point. Record 1352 also includes Signlnformation 1360 
describing the signs that would be seen by someone driving 
along the link. 

2.6 Server Software Components (FIG. 5) 

Referring to FIG. 5, server system 125 includes software 
that executes on server computer 310 (FIG. 3). This software 
includes a navigation application 512, which is used to 
interact with the in-vehicle systems. Navigation application 
512 is coupled to a communication interface 514, which is 
used to communicate with telephone interface 320 (FIG. 3). 
Navigation application is also coupled to a GPS interface 
516 that is coupled to GPS receiver 325 (FIG. 3). 

Navigation application 512 also makes use of a number of 
databases that it accesses through a data interface 518. 
Server system 125 includes a server map database 520 that 
includes the complete road network 700 (FIG. 7). This 
database is derived from map information 360 provided 
from map provider 160. The map information is processed 
by a map processor 550 that reformats the map information 
to form server map database 520. The same map information 
is used to derive the map information that is stored in the in 
vehicle databases 432 in the vehicles. Map processor 550 
can be implemented as a software module that executes on 
server computer 310, or can alternatively execute on some 
other computer allocated to the reformatting task. By deriv- 
ing both the server map database and the in-vehicle map 
database from the same map information, consistency 
between the in-vehicle and the server data is guaranteed. 

Navigation application 512 also makes use of a yellow 
pages database 522 that it uses to convert the telephone 
number of a desired destination to a street address in a 
"reverse" number lookup. The information needed to con- 
struct yellow pages database 522 is provided by an external 
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information system 130, such as a telephone company or a located at the centralized server. For instance, the centralized 

publisher of telephone directories, server can be some distance from the vehicles. The GPS 

Navigation application 512 also makes use of a traffic receiver and antenna are located nearer to the vehicles than 

database 524. Information in traffic database 524 includes ^ centralized server. This makes the GPS correction data 

typical link speeds that it uses for route planning. The 5 more accurate since the server system's GPS receiver is then 

information comes from a combination of an external infer- closer 10 & & vehicles at which the GPS location estimates 

mation system 130, such as from a government run traffic are bein S estimated. Also, a server system can have multiple 

monitoring authority, and from logging data obtained from G U PS t"*™* m ^ e £ nl Nations. The server system then 

probe vehicles (see Section 3.5). If probe vehicles are used choo ^. s the closest G ™ receiver to a vehicle for which it is 

to collect traffic information, then traffic information can to Providing correcUon data. In ithis way, a single server system 

also be provided by the server system to the external traffic ^^n^^ 

. , r . J 1 common GPS correction data may not be effective due 

information: system. geographic variations in the correction terms. 

3 System Operation FIGS. 15A-B and 16-18 For types of receive d destination specifications, 

3.1 General Procedure anc j m particular, a destination specification in terms of a 

System operation involves cooperation between is class Q f "yellow pages" categories, the destination is not 

in-vehicle system 105 and server system 125 (see FIG. 1). m n y specified at this point. If this is the case (fine 1556) then 

The procedure followed from the time at which an operator further operator input may be required in response to sec- 

of a vehicle begins specifying a destination to the time at ondary specification data provided by the server system. The 

which the vehicle reaches the specified destination is illus- server system sends the secondary data to the vehicle (line 

trated in the pseudocode listing in FIGS. 15A-B and 16-18. 20 1557). For instance, if the operator specified the destination 

Referring to FIG. 15 A, the procedure followed by in terms of a yellow pages category, the server system 

in-vehicle system 105 (FIGS. 1, 2) from the time at which provides secondary data with the specific listings in that 

the operator begins specifying the desired destination to the category that are near the vehicle's location, 

time that the in-vehicle system can begin guiding the opera- Referring back to FIG. 15A, the in-vehicle system accepts 

tor to the destination shown. The in-vehicle system first 25 the secondary destination specification data (line 1507). 

accepts a destination specification from the operator (line Using this data, the in-vehicle system presents the data to the 

1502). This can take several separate interactions with the operator and accepts a secondary destination specification 

operator, for instance the operator selecting a city, then a from the operator, for instance as a choice from the list of 

street, and then a street number. Various types of destination destinations defined in the secondary specification data. The 

specification procedures are supported by the system, as 30 secondary destination specification is sent to the server (line 

described further below (see Section 3.2.1) 1509), At this point, the server system has a completely 

The in-vehicle system also determines the vehicle's initial specified destination, 
location or data related to the vehicle's initial location, and Turning back to FIG. 15B, the server system now deter- 
in some versions of the system the orientation of the vehicle mines a route (see Section 3.2.4) from the vehicle's location 
(line 1503). The location or location-related data includes 35 to the specified destination (line 1561). The server system 
one or more of (a) a GPS location estimate or pseudorange also determines a spot map around the vehicle's location that 
measurements obtained at the time that the navigation it will download to the vehicle (line 1562). The server 
request is being made, (b) past GPS-based location system also determines whether to download spot maps 
estimates, and (c) dead-reckoning from previous GPS-based around maneuver points, for instance, based on the corn- 
location estimates or from maneuver locations. Starting 40 plexity of the maneuvers, and determines the spot maps 
location estimation is discussed further below (see Section around those maneuver points. 

3.2.2) The server system sends the planned route, the spot map, 

After having accepted the destination specification from and the GPS correction data to the in-vehicle system (line 

the operator, and location data related to the vehicle's 1563). 

current location, the in-vehicle system establishes a com- 45 Referring back to FIG. 15 A, the in-vehicle system 

munication session with the server system (line 1504). The receives the planned route, spot map, and GPS correction 

in-vehicle system establishes the communication session by data from the server system (line 1512) and closes the 

making a cellular telephone call to the server system and communication session with the server (line 1513). 

then establishing a data communication session with the Referring now to FIG. 16, the vehicle is now prepared to 

server system using its modem. 50 guide the operator in a startup maneuver from its initial 

The in-vehicle system then sends the location data and the location onto the planned route. First, the in-vehicle system 

destination specification to the server system (line 1505). initializes its estimated location. The server system provided 

Referring now to FIG. 15B, the server system accepts the GPS correction data that the in-vehicle system provides to 

communication session from the vehicle (line 1552) and its GPS receiver in order to increase the accuracy of the 

receives the location data and the destination specification 55 location estimates provided by its GPS receiver. The GPS 

(line 1553). correction data that the server system provided is only valid 

The server system receives signals from multiple GPS for a short time. After an interval of approximately one 

satellites 140 and computes GPS correction data for each of minute from the time the GPS correction data was obtained 

the satellites (line 1554). The server system then determines by the server system from its GPS receiver, the in-vehicle 

the vehicle's location (line 1555). In determining the vehi- 60 system stops using the correction data and uses standard 

cle's location, if the in-vehicle system provided raw GPS GPS instead. As is discussed further below, GPS correction 

data, such as pseudorange measurements to GPS satellites data may be obtained at other times during a trip, and in such 

140, the server system applies the GPS correction data it has cases, the in-vehicle system provides the correction data to 

computed to the raw GPS data that the vehicle provided to its GPS receiver for a fixed interval from the time that the 

compute the vehicle's location. 65 data was generated by a GPS receiver. 

In alternative versions of the server system, the server's During the startup maneuver, which is the initial portion 

GPS receiver (or at least its GPS antenna) is not necessarily of the trip until the vehicle is following the planed route, the 
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in-vehicle system tracks the location of the vehicle using the rate gyroscope, or from successive GPS location estimates 

differential GPS location estimates until the GPS correction from which changes in directions are detected, provide a 

data is too old, and then tracks the vehicle using uncorrected clear indication of the maneuver point. 

GPS location estimates (line 1604). The in-vehicle system If a maneuver is detected (line 1718) then the in-vehicle 

displays the spot map along with an indication of the 5 system updates its dead reckoning location estimate based 

vehicle's estimated location and a representation of the on the location of the maneuver (line 1719). Also, the 

planned route (line 1605). When the in-vehicle system in-vehicle system uses the downloaded location of the 

detects that the vehicle is following the planned route, the maneuver point to compute its own GPS correction data 

startup maneuver phase is completed and a turn-by-turn (line 1720). In particular, the in-vehicle system computes the 

route following phase begins, to deviation in latitude and longitude at the maneuver point and 

Referring now to FIG. 17, the route following procedure applies these deviations as corrections to the latitude and 

is based on notifying the operator of each of the links along longitude position estimates output from its GPS receiver for 

a planned route. While traveling along the route, the a one minute interval after the maneuver. Alternatively, the 

in-vehicle system maintains two location estimates for the in-vehicle system uses the location of the maneuver point 

vehicle. The first is based on GPS estimates, or on DGPS 15 and the pseudorange measurements obtained by the vehi- 

estimates if current GPS correction data is available. The cle's GPS receiver at the time of the detected maneuver to 

second location estimate is based on a "dead reckoning" compute new GPS correction data that are used for a one 

procedure. This procedure assumes that the vehicle is prop- minute interval after the maneuver, 

erly following the planned route. The dead reckoning uses Note that there are times when a maneuver is not detected, 

the locations of the maneuver and way points along the 20 for instance if it involves only a slight turn thai is not 

planned route and information from the vehicle sensors, in accurately detected using the vehicle sensors. In such a case, 

particular, from the velocity sensor, to update this second the in-vehicle system continues the dead reckoning proce- 

location estimate. If the vehicle is truly following the route, dure under the assumption that the vehicle has stayed on 

then the two location estimates should remain close to one route. Such maneuver points that are not detected are 

another. Note that this dead reckoning procedure does not 25 essentially treated in the same way as way points from the 

need to use heading estimates to track the vehicle's position point of view of tracking the dead reckoning location of the 

since the vehicle is assumed to be traveling along the vehicle. 

planned route. The route following procedure continues from link to link 
Along each link, after the initial maneuver at the starting along the route until the destination is reached (line 1725), 
node of the link, the in-vehicle system initializes an off-route 30 Referring now to FIG. 18, the off-route routine first 
tolerance. This tolerance is the allowable disparity between involves a dead-reckoning position correction procedure 
the GPS and the dead reckoning location estimates. The (lines 1802-1810). If for the direction of travel matches the 
tolerance grows from an initial value established right after planned route for an interval, for instance, of 75 feet after the 
a maneuver to account for a growing inaccuracy in the difference between the position estimates was detected, then 
estimates, due, for instance, to calibration inaccuracies in the 35 the dead reckoning position is updated to be the closest point 
velocity sensor and aging of the GPS correction data. The along the planned route to the (D)GPS position estimate 
off-route tolerance is initialized to 150 feet and grows (lines 1804-1805). In this way, if the deviation in position 
linearly to a maximum of 500 feet at a rate of about 1 foot estimates is due to inaccurate tracking of the distance along 
per 100 feet traveled. the route, the location correction procedure should success- 
While traveling to the next maneuver point (loop starting 40 fully overcome the error. If the deviation between the 
at line 1704), the vehicle increases the off route tolerance (D)GPS estimate and the dead-reckoning estimate is now 
(line 1705), tracks its dead reckoning position (line 1706), less than the off-route tolerance, the in-vehicle system 
and tracks its GPS or DGPS position (line 1707) (depending resumes the route following procedure (line 1808). If on the 
of whether current GPS correction data is available). other hand, even the closest point on the planned route is still 
If at any time the difference between the dead reckoning 45 more than the off-route tolerance from the (D)GPS position, 
position and the (D)GPS based position is more than the then the location correction procedure is not successful and 
off-route tolerance, then a off-route routine is initiated (line a route replanning procedure is initiated. 
1710). Referring still to FIG. 18, the route replanning procedure 
While traveling along a link, the vehicle eventually involves first estimating the vehicle's location on main roads 
reaches a point near the next maneuver. When the vehicle is 50 network 1000 (FIG. 10) that is stored in the vehicle. The 
estimated to be within a distance window of the next GPS location estimate is used to find a link along which the 
maneuver, then the operator is notified by the in-vehicle vehicle is traveling (line 1811). 

system using graphical and aural output of the upcoming Once the vehicle has been located on the main roads 

maneuver. The size of the notification window depends on network, the in-vehicle system calculates a best route that 

the road class being traveled on, which is related to the time 55 leads to one of the maneuver or way points along the 

prior to a maneuver that an operator is notified of the previously planned route (line 1813), 

maneuver. For instance, on a highway, an operator is notified The newly planned route to the maneuver or way point on 

of a maneuver, such as exit from the highway, at a farther the previous route, along with the remaining portion of the 

distance from the maneuver that the distance than from a previously planned route then becomes the new planned 

maneuver in a residential neighborhood. 60 route which replaces the previous one (line 1815). The 

Also while traveling along the link, the in-vehicle system Unk-by-link route following procedure is then reentered 

attempts to detect the precise point at which the next (line 1816). 

maneuver is carried out. When the vehicle is within a Specific aspects of the general operation of the system are 

distance window of the next maneuver, the in vehicle system described in the following sections. These aspects includes 

attempts to detect the maneuver. For instance, if the maneu- 65 route planning, including in-vehicle destination specifica- 

ver involves making a right angle turn, the signals from the tion as well as computation of the best route at the server 

in-vehicle sensors, such as from a magnetic compass or a system. The specific aspects also include the guidance 
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operations carried out by the in vehicle system, as well as 
route replanning operations carried out by the in-vehicle 
system when it detects that the vehicle is off route. In 
addition, operation of the system in which the fleet of 
vehicles is used to collect traffic related data is described 
below. 

3.2 Route Planning (FIGS. 15A-B) 

Route planning involves several steps, as shown in FIGS. 
15A-B. In particular, the route planning operation includes: 

Destination specification (line 1502, FIG. 15A) 

Starting location determination (line 1503, FIG. 15A) 

Querying the server system (lines 1504-1510, FIG. 15 A; 
lines 1552-1560, FIG. 15B) 

Route planning (line 1561, FIG. 15B) 

Route and spot map downloading (lines 1562-1563, FIG. 
15B, line 1512, FIG. 15A) 

Specific operations carried out by the in-vehicle and 
server systems in each of these steps are described in the 
following sections. 
3.2.1 Destination Input 

As shown in FIG. 15A (line 150(2), the first phase of 
navigation to a desired destination is destination input by the 
operator of the vehicle. In-vehicle system 105 (FIGS. 1, 2) 
enables the operator to specify a destination in a number of 
different ways. In general, the in-vehicle system uses 
in-vehicle database 432 (FIG. 4) to provide alternative in 
scrolling lists from which the operator chooses. A destina- 
tion specification can be one of: 

A street address (e.g., city, street, and number), 

A point of interest (e.g., city, type of point of interest, and 
a selection from a list), 

A "yellow pages" listing (e.g., type of listing, and a 
selection from a list), 

A telephone number of the destination, 

A pair of cross streets, 

A selection from a list of recently specified destinations, 
and 

A selection from a list of previously stored destinations in 
a user's "profile". 

In an initial interaction with the system, the operator first 
specifies what method of destination input will be used, for 
example, by selecting from a displayed list of choices. 
3.2.1.1 Street Address Specification 

One way that the operator can specify a destination is by 
the street address of the destinatioo. The destination speci- 
fication in this case is a fully specified (country, state, city, 
street, number) combination. The user does not necessarily 
have to enter each of these fields in turn. For instance, the 
current (i.e., previously used) country and state can be used 
as defaults. 

Alternative sequences of field specifications can be used. 
In one sequence, the operator first selects a city from a 
scrolling list of cities in the current (country, state). Refer- 
ring to FIG. 11, the list of valid states is obtained from 
CityState table 1130. After the operator selects a desired city, 
the in-vehicle system presents a scrolling list of valid streets 
names in that city. The list of valid street names is obtained 
using AddressCityState table 1100, and associated 
AddressStreet table 1150, StreetRecord table 1160, and 
StreetName table 1170. After the operator selects a desired 
street, the operator enters a street number. The in-vehicle 
system validates the number using AddressStreet table 1150 
and AddressRange table 1180. 

In the above procedure, alternative methods of selecting 
from lists of valid names can be used, including scrolling 
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through a list using "up" and "down" buttons, and spelling 
a prefix of the name until it unambiguously specifies a full 
name. An alphanumeric keyboard is not necessarily pro- 
vided with this system. If one is not provided, the operator 
enters letters of a spelling, or digits of a street address, by 
moving a cursor to a display of the desired letter or digit and 
selecting that letter or digit. 

There are times when the city of the desired destination is 
not known. In that case, the city can be initially left 
unknown. The list of valid street names presented to the 
operator by the in-vehicle system is then all the streets in the 
current state. After the street name is selected, if the city is 
ambiguous, the operator selects from the list of possible 
cities and then proceeds to input the street number. 
Alternatively, disambiguation of the city of a destination 
street can be left until after a street number is also specified. 

3.2.1.2 Point of Interest Specification 

In specifying a destination by a point of interest (POI), the 
operator first selects from a list of types of points of interests. 
Examples of types of POIs include banking locations, gas 
stations, hospitals, and restaurants. Referring to FIG. 14, the 
list of valid types is obtained by the in-vehicle system from 
POIiypes table 1420. 

The operator can select a particular POI of the selected 
POI type in a number of ways. In a first way, the operator 
next selects a city in which to find the destination POT. 
Using POINameCity table 1430, the system displays a list of 
names, addresses and phone numbers of POIs of the selected 
type in the selected city. The operator then selects from the 
list of displayed POIs. The phone number can be useful, for 
instance, if the operator wants to call the destination, such as 
a restaurant, before deciding to travel to the destination. 

Rather than specifying the city, the system can display the 
POIs by their proximity to the current location of the 
vehicle. The GPS-based latitude and longitude estimates are 
compared to the Latitude/Longitude field of records in 
POIList table 1450, for POIs of the selected POI type. The 
in-vehicle system then displays the POIs in order of prox- 
imity to the current location rather than alphabetically. 

3.2.1.3 "Yellow Pages" 

In order to support an operator specifying a destination to 
the in-vehicle system using "yellow pages" listings, the 
in-vehicle database 432 does not have the capacity to 
include all the possible listings that an operator may be 
looking for. Instead, only the categories of listings are 
included, for example, "jewelry stores." The in-vehicle 
system first displays a list of categories from which the 
operator selects a particular category. The operator then 
selects a particular destination city, or requests listings in the 
proximity of the current location. The in-vehicle system 
presents a list of categories to the operator and the operator 
selects from the list. Note that the destination is not com- 
pletely specified at this point since a particular destination 
(i.e., a street address) has not yet been determined. 

After the communication session with the server is 
established, the server downloads the specific listings in the 
selected yellow pages category to the in-vehicle system, 
either according to the selected city, or according to the 
proximity to the vehicle's location. The operator then selects 
from the downloaded list. 

3.2.1.4 Other Destination Specifications 

Several optional ways of specifying a destination can also 
be supported by in the in-vehicle system. 

An operator can specify a destination by selecting a pair 
of cross streets. To support selection of a pair of cross streets, 
in-vehicle database 432 includes a table of valid pairs of 
main streets, and possible pairs of main and side streets or 
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even pairs of side streets. The operator selects a first street. If the vehicle was guided to the starting location during a 

A list of valid cross streets are then displayed and the previous navigation session, the starting location can be 

operator selects one from the list. based on dead reckoning along the previously planned route. 

As in destination specification by street number, if the city Once the server system provides GPS correction data to 

is not specified before specifying the cross streets, the city 5 me in-vehicle system, the in-vehicle system updates its 

is disambiguated after one or both of the street names are starting location using the GPS correction data (line 1602, 

selected FIG. ^ or ins 131106 * if fo c GPS correction data is pseu- 

An operator can specify a destination by specifying the doran S e <*™<*™ the in-vehicle system provides the 

telephone number of the destination. A complete telephone pseudorange correcUon data to its GPS receiver and receives 

directory is not stored in in-vehicle database 432, therefore, 10 ^ mae f. Vf™. cst ™« im , m t ^ s . GP * ' ecel Y" lf * e 

. ..-J. f . . . . . . . 1 . ' GPS correction data is offsets in latitude and longitude, the 

the validity of the telephone number, ot^er than perhaps the m . venicle tem lies these offeels l0 t^^ted 

validity of the area code, is not verified before the in-vemcle . fon { frQm ^ Gps feceiver 

system establishes the communication session with the 323 Server Query 

server system. The server system receives the telephone When me m . ve hicle system establishes a communication 

number and looks in up in a "reverse" telephone directory to 15 session with the server system (line 1504-1510, FIG. 15A), 

determine the street address of the destination. i t does so in two steps. First the in-vchicle system establishes 

As is described further below, individual operators can a cellular telephone connection to the server system, and 

have stored profiles that are stored in the vehicle and may then it establishes a modulated data session on the cellular 

have corresponding storage on the server system. This telephone connection. 

profile can hold typical destinations, such as "work," 20 In the first step, the cellular telephone connection is 

"home," "airport," etc. for which the operator has previously established by the in-vehicle system dialing a specific num- 

specified particular locations. ber to reach the server system. The in-vehicle system can 

An operator can specify a destination by selecting from handle typical error conditions that might be found in an 

the most recently specified locations. For example, the analog cellular telephone network, such as being out of 

operator may be returning to a recently visited work site. 25 range of the cellular system, or the cellular system not 

Alternative versions of the system allow specification of having the capacity to establish the call, 
a destination by street address, but the in-vehicle system In the second step, once the telephone connection is set 
does not have data with which to validate the address ranges up, the in-vehicle system attempts to establish a data con- 
fer the specified street. For instance, the in-vehicle system nection with the server system. Typical modems carry out a 
may not have the capability to validate any street numbers, 30 negotiation phase in which compatible modulation, 
or the destination may be outside a geographic range for compression, and error correcting protocols are selected. In 
which it has stored address range data. If the in-vehicle order to reduce the time needed to set up the communication 
system cannot validate the street address, it nevertheless session, a particular set of protocols is preselected, for 
establishes a communication session with the server com- example as the "lowest" common protocol that all vehicles 
puter. The server computer then completes the validation 35 support. The server system expects communication using 
procedure. this lowest protocol. This allows data to flow as soon as 
3.2.2 Starting Location Determination possible without waiting for the protocol negotiation phase 

The in-vehicle system sends to the server system either an to be completed. Since the amount of data to be transferred 

estimate of its position, or sends raw GPS data from its GPS is relatively small, the time taken in negotiating the best 

receiver from which the server system computes the vehi- 40 protocols would likely be larger than the time saved by 

cle's position (line 1503, FIG. ISA). sending the data using the negotiated protocol rather than 

There are situations in which the vehicle cannot receive with the preselected protocol, 

signals from the GPS satellites at its starting location. For 3.2.4 Route Planning 

example, this would be the case if the vehicle were in an Route planning at the server system (line 1561, FIG. 15B) 

underground garage. In such a case, the vehicle relies on 45 uses well known route finding approaches. In particular, two 

location estimates that the system made prior to reaching the instances of the well-known A* ("A-Star") graph search 

starting location. Furthermore, after a GPS receiver is first algorithm are used in conjunction with road network 700 

powered on, there can be a significant interval before which (FIG. 700). One instance of the A* algorithm starts at the 

it can provide location estimates. For example, the GPS starting location and one starts "backwards" from the 

receiver must locate each of the satellites that are in range, 50 desired destination. The A* algorithm is a type of "best first" 

and compute their locations in orbit. search approach. At any point executing the algorithm, the 

The in-vehicle system therefore maintains a history of actual distance along the graph from an initial node to a set 

GPS location estimates on an ongoing basis, even when the of intermediate nodes has been computed. A lower bound (or 

operator is not being guided along a route. This history is in some versions of the algorithm, an estimate) of the 

stored in a non-volatile memory in the in-vehicle system 55 distance from each of the intermediate nodes to the final 

before the system is shut off. Therefore, if GPS signals node is added to the actual distance. The intermediate node 

cannot be received at the starting location, the latest GPS with the lowest sum is extended. If the lower bounds are 

location estimate in the stored history is used. used, this algorithm produces the shortest path from the 

In addition to sending location related data to the server initial node to the final node. Using the two instances of the 

system, the in-vehicle system also sends speed and orienta- 60 A algorithm, a best path is chosen after there are interme- 

tion data. The orientation can be obtained from either past diate nodes in common for the two instances of the algo- 

consecutive GPS location estimates, or from the magnetic rithm. 

compass. The speed and orientation information is used by Alternatives to the A* route planning algorithms can be 

the server system, for example, to disambiguate which of a used. For instance, Dijstra's algorithm, or another type of 

number of nearby road segments the vehicle is on based on 65 best first algorithm can be used. 

the class of road segments and the allowable directions of Route planning can be based on a variety of criteria. A 

travel on those segments. shortest total distance uses the actual link distances in the 
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road network to determine the cost of a path. The lower 
bound on the remaining path can be straight-line distance 
between an intermediate node and the final node. Route 
planning can alternatively be based on lowest expected 
travel time. Travel time along a link can be based on an 5 
expected speed for different road classes, or can be based on 
specific speed data stored on the server system and associ- 
ated with particular links. For example, the server system 
may know thai certain links are congested with slower than 
expected speeds for their road classes. The route planning 10 
algorithm would then tend to avoid such a congested link if 
there are alternative routes that can be taken. 

Other alternative route planning approaches can also be 
used on the server system. For instance, routes can be 
constrained to follow particular road segments, and the cost 15 
of routes can include other factors than distance or expected 
travel time, such as toll fees along the route. 
3.2.5 Route and Spot Map Download 

Referring to FIGS. S and 9, the server system downloads 
a route as a sequence of links joined by maneuver points, and 20 
downloads spot maps as small graphs around the starting 
location or the selected maneuver points (lines 1562-1563, 
FIG. 15B, line 1512, FIG. 15A). In order to reduce the 
download time needed, this data is represented as a compact 
data structure. 25 

The planned route is downloaded as a sequence of route 
links using a compressed format. For each link in the 
planned route, the downloaded information includes: 

The latitude and longitude of the starting node (maneuver 
point) of the link, encoded as 32-bit integers in units of 30 
10" 3 degrees, 

Turn information, encoded as an index representing mes- 
sages such as "turn right," "keep left," etc., 
The number of "arms" at the current maneuver point, ^ 
The number of way points before the next maneuver, and 
The rank (e.g., the size or classification) of the road 

segment associated with this link. 
In addition, for each way point, the data for a link 
includes: 40 
The change in latitude and longitude from the previous 
way point, or from the starting node for the first way 
point, encoded as 12-bit integers in units of 10" 5 
degrees. 

Note that 12-bit encoding of the change in latitude or 45 
longitude Limits the change to approximately 2 12 xl0~ 5 =0.04 
degrees. If a segment of the route planned by the server 
system includes a greater change between successive 
maneuver or way points, the server system inserts additional 
way points that are sufficiently close to encode the changes 50 
in the 12-bit quantities. 

In addition, for each link, the downloaded data includes: 
The length of text fields, if any, associated with the name 
of the street associated with the link, and the name of 
the street to be turned onto at the next maneuver point, 55 
and with any signage or other special information to be 
presented to the operator, and 
The text fields themselves. 

For each "arm" at a maneuver point, the downloaded data 
includes data related to the angles at which the intersecting 60 
streets join at the maneuver point, thereby allowing a 
relatively accurate graphical representation of the maneuver 
to be displayed to the operator. 

This route download format provides a compact repre- 
sentation that can be downloaded quickly from the server to 65 
the vehicle. Alternative versions of the system can take 
advantage of data in the in-vehicle database to reduce the 
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amount of data still further, for example, by referencing 
stored street names or by using references to nodes in the 
main roads network that is already stored in the vehicle. 
Alternative versions of the system can also include addi- 
tional information related to the links. For example, link 
travel speeds can be downloaded, particularly if the links are 
known by the server to be exceptionally congested. 

An alternative approach to route downloading includes 
use of predefined sequences of road segments that are stored 
in the in-vehicle systems. The server system replaces an 
sequence of road segments, maneuver points, and 
waypoints, with a reference to the stored predefine sequence. 
In this way, typically traveled routes, for example, along a 
highway do not have to be downloaded explicitly. The server 
system can periodically update the stored sequences in the 
vehicles to reflect the typically requested routes by those 
vehicles. Alternatively, the in-vehicle system retains a 
memory of previously downloaded routes, and the server 
can refer to portions of those routes when downloading a 
newly planned route. 
3.3 Guidance 

Guiding the operator to the desired destination involves 
several aspects of operation of the in-vehicle system. These 
include: 

A startup maneuver (FIG. 16), 

Dead reckoning location tracking (FIG. 17, line 1706), 
GPS location tracking and off-route detection (FIG. 17, 

lines 1707-1710), and 
Maneuver notification and detection (FIG. 17, lines 

1712-1722). 

These aspects are described in the following sections. 

3.3.1 Startup Maneuvers 

There are several reasons that an operator may not be able 
to follow an initial route. One is inaccuracy of the initial 
location of a vehicle. For instance, the GPS may indicate that 
the vehicle is on a street, when in fact it is in a nearby 
parking lot or an adjacent street. Also, if a vehicle is pointing 
in the opposite direction on a street than the server system 
expects, then the vehicle is likely to go off route right from 
the very first step. Also, following directions at the start of 
a route can be difficult, for instance, due to the close spacing 
of side streets, inadequate signs, distractions, traffic, etc. 

For these and other reasons, the system does not rely on 
an operator making no mistakes right from the very initial 
starting location. Instead, the starling location is used to 
determine the spot map that is downloaded to the vehicle. 
The spot map typically covers only two or three intersec- 
tions in any direction from the starting location. The planned 
route is shown in conjunction with the spot map, as is the 
vehicle's DGPS based location. The operator uses this map 
representation to get onto the planned route. 

Once the vehicle is on a segment of the planned route, and 
traveling in the correct direction, the turn-by-turn guidance 
phase begins. 

3.3.2 Dead Reckoning Location Tracking 

Once the in-vehicle system enters the turn-by-turn route 
following (guidance) phase, the in-vehicle system maintains 
a dead reckoning location estimate of the vehicle. In general, 
the in-vehicle system tracks the vehicle under the assump- 
tion that the operator is trying to follow the instructions. 
Dead reckoning is based on converting the velocity signal 
from velocity sensor 232 and the straight line approxima- 
tions of the links between maneuver or way points along the 
planned route into an updated location. In particular, if the 
in-vehicle system assumes that the vehicle is at a known 
maneuver point, then as the vehicle travels a distance 
measured according to the velocity signal, the in-vehicle 
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system estimates the vehicle's location as the point that is 
the measured distance along the sequence of links from the 
maneuver point. The locations of the nodes at the ends of 
each link are known to the in- vehicle system, therefore, the 
in-vehicle system essentially uses the direction of the links 
to estimate the direction that the vehicle is traveling as it 
leaves the maneuver point, and as it passes over subsequent 
links on the route. 

Dead reckoning relies on a known correspondence 
between the velocity signal and the distance traveled. Sev- 
eral factors affect this correspondence, including tire pres- 
sure which is affected by temperature, which affects the 
circumference of the tires. In order to improve the accuracy 
by which the distance traveled is estimated from the velocity 
signal, an ongoing calibration procedure is supported. When 
the in-vehicle system detects a maneuver, it compares the 
velocity sensor-based distance estimate and the map-based 
distance estimate. The in-vehicle system adjusts a scale 
factor relating the number of velocity signal pulses to the 
distance traveled so that the velocity sensor and map-based 
traveled distance estimates match. 
3.3.3 GPS Location Tracking and Off- Route Detection 

While the operator is being directed from maneuver to 
maneuver along the planned route, the in-vehicle system 
continuously updates its GPS-based location estimate while 
the GPS satellite signals are received. In addition, there are 
intervals during which the in-vehicle system has current 
GPS correction data that it provides to the GPS receiver in 
order to improve the accuracy of the GPS-location 
estimates, for instance, in a differential correction mode. 

GPS correction data is received by the in-vehicle system 
from the server system when the planned route is down- 
loaded. In alternative versions of the system, there may be 
other times at which the server provides differential correc- 
tion data, for instance during communication sessions that 
are established for another purpose. 

The in-vehicle system can also compute its own GPS 
correction data when it knows its location precisely. The 
in-vehicle system estimates its location very accurately 
when it detects that a planned maneuver is executed by the 
operator, since an accurate location of each maneuver is 
downloaded for the server system when the planned route is 
downloaded. 

Therefore, while negotiating the planned route, the 
in-vehicle system receives a stream of GPS or DGPS based 
location estimates. These location estimates are compared 
on an ongoing basis to the dead reckoning position estimates 
also maintained by the in-vehicle system. 

After a vehicle executes a maneuver, and in particular 
when GPS correction data is computed based on the location 
of the maneuver point and the raw GPS data recorded when 
the vehicle passes through the maneuver point, the GPS- 
based location and the dead-reckoning positions should 
match. As a vehicle correctly passes along the planned link, 
the dead-reckoning position and the GPS-based position are 
expected to diverge somewhat for several reasons. These 
reasons include increased error in the GPS estimates, and 
possible map errors. 

The GPS correction data is provided to the GPS receiver 
for approximately one minute after the maneuver. During 
that time, their utility slowly decreases, that is, the error of 
the DGPS based location estimates slowly increases. After 
the GPS correction data is no longer used, the GPS error is 
expected to remain within a fixed range. 

The error in the dead reckoning position estimate grows 
primarily due to error in estimating the distance traveled 
along the links. Also map errors, both in the length of links 
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and the location of waypoints or maneuver points, can 
contribute to a growing dead reckoning position error. 

The combination of a growing error in each of the two 
terms is compensated for by using an increasing tolerance 
beyond which an off-route condition is detected by the 
in-vehicle system. The tolerance starts at 150 feet. The 
tolerance increases at a rate of 1 foot per 100 feel traveled 
until the tolerance reaches 500 feet. 

If at any point the difference between the two location 
estimates exceeds the tolerance, the in-vehicle system 
detects an off-route condition it attempts to correct the dead 
reckoning position estimate and it that is unsuccessful, it 
executes a route replanning procedure (see Section 3.4). 
3.3.4 Maneuver Notification and Detection 

Maneuver notification and detection both use the dead 
reckoning position estimate, or more particularly, use a dead 
reckoning estimate of the scalar distance traveled along the 
planned route from a previously detected maneuver. 

The in-vehicle system gives instructions to the operator at 
distance prior to when the in-vehicle system expects the 
vehicle to execute the next maneuver. This accounts for both 
the reaction time needed by the operator, as well as inac- 
curacy in the system's estimate of the distance to the next 
maneuver. In order to account for the different amount of 
time or distance needed by an operator to act on a command, 
the instructions are given farther from the next maneuver on 
high-speed links, such as highways, than on small residential 
streets. Each road class has a fixed distance from an upcom- 
ing maneuver at which the next instructions are given. 

The in-vehicle system also gives voice prompts as the 
vehicle enters the notification window. Graphical and text 
prompts and instructions are displayed at least from the 
point that the vehicle enters the notification window, and can 
be displayed sooner. 

In a distance-based window around the point at which the 
in-vehicle system expected the next maneuver to be carried 
out, the in-vehicle system attempts to detect the exact point 
at which the maneuver occurs. For instance, if the maneuver 
involves a right angle turn, the output of the onboard 
magnetic compass or the GPS-based direction estimate is 
used to reliably detect the maneuver. Also, sensing of the 
vehicle speed to detect certain classes of maneuvers, such as 
stopping at a toll booth. 

Certain maneuvers cannot be detected with high accuracy. 
For instance, a turn may be too gradual to detect using the 
signal produced by a magnetic compass. If the vehicle leaves 
the maneuver detection window without detecting the 
expected maneuver, then the in-vehicle system simply con- 
tinues to update the dead reckoning position until a subse- 
quent maneuver is detected. 
3.3.4.1 Display and Voice Commands 

In addition to receiving audible instructions, the maneu- 
ver notification and instructions are provided on the 
in-vehicle display. The display include: 

A graphical illustration of the "distance to go" until the 
next maneuver, or example as a bar chart that gradually 
fills as the link is traversed, 

A digital "distance to go," for instance a number in miles 
or feet, 

A graphical representation of the upcoming road geom- 
etry at the next maneuver, for instance showing the 
angles at which all roads meeting at the next intersec- 
tion joint, and 

Sign text that should be visible at the next maneuver 
point. 

Voice instructions include a variety of pre-stored phrases, 
including commands to notify a driver of an upcoming 
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maneuver, and commands to instruct and operator to make 
a maneuver at the point thai the instruction is give. 

3.4 Route Replanning 

When the in vehicle system detects that a vehicle is off the 
planned route, it executes a route replanning procedure 5 
(FIG. 18). The first step is to determine where the vehicle is 
traveling on the main road network 1000, which is stored in 
in-vehicle database 432. 

The in-vehicle system uses the GPS (or DGPS) based 
latitude and longitude estimates to search through the list of 10 
nodes in MasterNode table 1310. Sequential GPS-based 
position estimates, or the output of the magnetic compass, 
are used to determine a direction of travel along a link 
joining to adjacent nodes. This then determines which link 
in UnkSegments table 1330 the vehicle is traveling on, and 15 
the direction of travel along that link. 

The in-vehicle system then executes a shortest path search 
(e.g., an A* search) starting at that link to one of the 
maneuver or way points along the planned route. A number 
of points, or alternatively all points, on either side of the last 20 
maneuver point are used as points at which the replanned 
route can join up with the previously planned route. For 
instance, ten points before and after the last detected maneu- 
ver point can be used. Limiting the number of points can 
reduce the amount of computation (time and memory) 25 
required to replan the route. If there are fewer than ten 
remaining points, then the actual desired destination is one 
of the points that the replanned route can "join" to planned 
route. 

As in the server system based route planning approach, 30 
the in-vehicle system uses an A* algorithm to plan the route. 
The starting point is determined using the scanning of 
MasterNode table 1310, as described above. As intermediate 
nodes are considered in the A* search, the lower bound on 
the distance to the desired location is minimum over the 35 
maneuver and way points near the last detected maneuver 
point of the sum of the straight -line distance from the 
intermediate point to the maneuver or way point plus the 
previously calculated distance along the previously planned 
route from that maneuver or way point to the desired 40 
destination. In this way, the best point of rejoining the 
previously planned route is found. 

As in the server system based route planning, the cost of 
traveling over a link can be based on the length of the link, 
an estimate of the time to travel over the link based on the 45 
road class of the line, or an estimate of the time to travel a 
link based on specific road speed information associated 
with that link. 

3.5 Floating Vehicle Data Collection 

Referring to FIG. 19, navigation application 512 which is 50 
part of server system 125 makes use of a traffic database 524 
when planning routes that are based on expected travel time. 
In the description of the system above, traffic information 
provided from an external information system 130, such as 
from a government run traffic monitoring authority, is used 55 
to populate traffic database 524. 

In addition to relying on an externally provided traffic 
information, server system 125 makes use of some or all 
vehicles 100 as "probes** for collecting traffic information. 
Navigation application 512 receives the traffic information 60 
from the probe vehicles and feeds the collected traffic 
information back into traffic database 524 In addition, the 
server system optionally sends updated traffic information to 
the external information system. In this way, the vehicle 
navigation system can be a source of traffic information in 65 
addition to, or instead of, being a consumer of traffic 
information from external information system 130. 



Two modes of data collection are used. First, ongoing 
traffic "profile" data is collected by the in-vehicle systems in 
probe vehicles. Occasionally, the probe vehicles upload their 
collected data to the server system and the server system 
updates its traffic database based on the uploaded informa- 
tion. In the second mode, the in-vehicle systems in the probe 
vehicles detect when the vehicle's speed is significantly 
slower than would be expected based on the class of road 
being traveled, on or based on traffic related data that is 
stored in the vehicle and which relates the expected speed to 
the road segment being traveled on. When the in-vehicle 
system detects that the vehicle's speed is slower that 
expected, that is, it detects any exception from expected 
traffic conditions, it immediately reports the exception to the 
server system so that the server system can update its traffic 
database 524 to reflects unexpected traffic conditions. 
3.5.1 Traffic Profile Collection 

In the first mode of traffic data collection, navigation 
application 412 in in-vehicie system 105 of a probe vehicle 
collects on an ongoing basis a history (a profile) of the speed 
that the vehicle travels on links of the main roads network 
(or equivalently the transit times on the links). The 
in-vehicle system collects the traffic profile data indepen- 
dently of the guidance function. That is, the vehicle does not 
have to be guided by the navigation system in order to 
collect traffic profile data. The navigation application stores 
the time of day and the speed traveled on each link in a link 
speed log 1920. 

In order to build up link speed log 1920, the in-vehicle 
system tracks the vehicle's location on main roads network 
1000 that is stored in in-vehicle database 432. Using the 
GPS location estimates it receives from its GPS receiver, the 
in-vehicle system detects when the vehicle is following a 
road segment (link) of the main roads network. The 
in-vehicle system records the time the vehicle takes to travel 
from one end to the other of the link and stores a reference 
to the link, the time of day, and the speed traveled along the 
link in the link speed log. As the vehicle travels over 
multiple links of the main roads network, a series of travel 
times is logged, each associated with a link that was tra- 
versed. 

Occasionally, for example when vehicle leaves the main 
roads network, or periodically, such as daily, the in-vehicle 
system sends the logged profile information it has stored in 
link speed log 1920 to the server system over a data 
connection that the in-vehicle system initiates over a cellular 
telephone connection with the server system. After it has 
sent the information, the in-vehicle system clears its link 
speed log. 

The operator of the vehicle has the option of enabling or 
disabling either mode of data collection through the user 
interface of the in-vehicle system. Also, the server system 
can enable (or request) either type of collection. For 
instance, the server system can enable more vehicles if it 
needs more data, and disable data collection in some 
vehicles if it is receiving more data than it needs. 

At the server system, navigation application 512 receives 
the logged speed information from a number of probe 
vehicles. Using this collected information, the navigation 
application updates traffic database 524. For example, the 
navigation application incorporates the reported speeds for a 
particular link into an average speed for that link that is 
stored in its traffic database. Optionally, the server system 
provides the updated traffic information to external infor- 
mation system 130. 

On the server system, traffic database 524 includes an 
average link speed for each link (in each direction), as well 
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as a start and a stop time for a morning and an evening rush time when no more exceptions are reported by probe 

"hour" (busy period). For each busy period, the traffic vehicles for those links. 

database includes the average speed during that period. Operation of the exception data collection mode does not 

Various alternative intervals can be used. For instance, necessarily require intervention of ihe operator. The operator 

equal five-minute intervals can be used, as can unequal 5 of a probe vehicle can explicitly enable or disable exception 

intervals, such as 1 hour intervals in the middle of the night reporting. Also, the in-vehicle system can be configured so 

and five-minute intervals at typically busy periods. mat lhe operator & ^ed to confirm the validity of exception 

Optionally the average link speeds stored in the server mformati0 D before it is sent to the server system. For 

system's traffic database 524 are downloaded and stored in lhe m . vehicle tem can dis ^ lhe exceptioD 

a link speeds database 1910 in the in-vehicle system of each w m tQ me oi aQd ^ l0 / m ^ a buU00 

vehicle. This link speeds database is used, for instance, by • .* T- *u . .L ,. . , c \ 4 1 

4 , . , . , t r , , ' , ' indicatmg that the message is valid before it is sent to the 

the in- vehicle system when reclaiming a route bases on a & . ™. « < j L ■ 

, t 4 , J , t . 4 . r & server system. This confirmation approach avoids having a 

shortest expected travel time. u-i _* u i j * j. . 

3.5 2 Excetion Re ortin vehicle report an exception when slow speed is due to a 

. xcep ion epo ing non-traffic related reason, such as stopping for gas along the 

In the second mode of traffic data collection, the J5 ^ ±-r © © © 

in-vehicle system makes use of information in its link speeds , ' c .l. 

* . miA u- u • i j . * . ! j r i, In a alternative version of the system, exceptions are 

database 1910, which includes expected travel speeds for all , . t . . , , J , . ' , r 

. , ^ , ; rtn w , v . . logged rather than immediately reported to the server sys- 

the links in mam roads network 100. Multiple travel tunes . • u- i . *u i j .u i j 

Jf u r i r • . « .r*u tem. The in-vehicle system then uploads the logged excep- 

are stored for each link, for instance, to account for the . . * . . r . L * i j 

. 4 . j . , -JT- uons to the server system in the same way that it can upload 

variations due to morning and evenmg busy periods. For 2Q ^ q ^ data 

each link, the following information is recorded: ^ 6 Server Control 

TVpical expected speed In ^ alleraalive version of the system, the system con- 
Start and end times of the morning busy penod ^ok the vehicle data collection, for instance, to limit the rate 
Expected speed during the morning busy period a! wn ich it receives data from probe vehicles, or to receive 
Start and end times of the evening busy period 25 data related to particular regions or roadways. Alternative 
Expected speed during the evening busy period methods of controlling the collection include the following. 
Alternatively, other types of intervals can be used to store In a first alternative, the probe vehicles do not transmit 
the speed information. Also, rather than relying on specific their logged speed data unless queried by the server system, 
speed information for a link, the in-vehicle system can The server system polls (interrogates) vehicles to receive 
alternatively base the typical expected speed for a link on the 30 their logged speed data. In one approach, the server system 
class of the link. For instance, a link on a class 4 (highway) polls vehicles based on the geographic region in which the 
link can be typically expected to be close to the speed limit vehicles typically travel. For instance, if the server system 
(e.g., 55 MPH). does not have up-to-date data for roads in a region, it polls 
As in the profile data collection mode, the in-vehicle vehicles that typically travel in that region. To poll a vehicle, 
system of a probe vehicle tracks the location of the vehicle 35 the server system places a cellular telephone call, or other- 
using GPS location estimates as it traverses links of the main wise notifies the vehicle, the in-vehicle system. The 
roads network, and detects when the vehicle traverses par- in-vehicle system receives the call and provides its logged 
ticular links in the main roads network. The in-vehicle speed data to the server. For example, an alternative to 
system detects that a traffic exception has occurred if a travel placing a telephone call is to broadcast a message to a 
speed along a link is substantially slower or faster than 40 number of vehicles over a broadcast channel, such as on a 
expected (e.g. 75% of the expected speed or slower) for that sideband of a commercial radio broadcast. In another 
link at that time of day. approach to this alternative, the server system polls vehicles 
When a traffic exception occurs, the in-vehicle system for which it has recently provided planned routes and which 
establishes a communication session with the server system it expects will have logged speed data for road segments on 
by placing a cellular telephone call to the server system. The 45 those routes. 

in-vehicle system transmits a short data message encoding In another alternative, the in-vehicle systems place the 

the exception, identifying the link and the travel speed, to the calls to the server system to transfer logged speed data, but 

server system. the server system has previously provided instructions to the 

In an alternative approach to exception reporting, a in-vehicle system regarding when to initiate that call. For 

vehicle makes a probabilistic choice of whether to transmit 50 instance, when the server system provides a planned route to 

the exception message. In this alternative, not all vehicles the in-vehicle system, the planned route is accompanied by 

which encounter the exception transmit to the server system, an instruction to call the server system after the vehicle has 

thereby reducing the communication load on the server passed a particular road segment, 

system. In another alternative, whenever an in-vehicle system 

The server system receives the exception message from 55 calls the server system, the server system optionally requests 

the in-vehicle system. The server system updates traffic the vehicle's logged speed data. In the case that the vehicle 

database 524, which it uses to plan routes, based on the is calling for a route planning service, the data transfer 

exception messages it receives from the probe vehicles. If occurs during the interval between the upload of the desired 

there is a sufficient "density" of probe vehicles on the road destination and the start of the download of the planned 

network, the server system will typically receive exception 60 route, or in any other interval that would have otherwise 

messages from multiple probe vehicle. Therefore, been unused for data transfer from the vehicle to the server 

optionally, the server system can require that two or more system. 

probe vehicles report an exception (i.e., a traffic exception is In another alternative, when the server system provides a 

confirmed by another vehicle) before updating its traffic planned route to an in-vehicle system, the planned route 

database. 65 includes the server system's up-to-date expected link times 

The server system resets its expected speeds for the links (i.e., the link times reflect recently received probe data). In 

on which exceptions have been reported after a period of this alternative, traffic exceptions on a segment are not 
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reported to the server if the server system was already aware Each of these approaches are described in the following 

of the exception at the time that it planned the route. sections. 

3 7 Data Fusion 41 Physical Replacement of the Storage Device 

, . . e , , Referring to FIG. 20A, in a first approach, static storage 

In alternative versions of the system, the server system 5 in m ^ 210 [q system 105 is a 

receives traffic related informaUon from external inforrna- removaMe devke . For insttoce> slalic slorage 222 can be a 

lion services. For instance, the server system receives traffic PCMCIA card housing a magnetic disk or a flash memory 

incident reports (e.g., breakdown reports) that it uses to system. 

predict slow travel speeds, rather than waiting to receive Updating the in-vehicle system involves replacing slorage 

data from probe vehicles for those segments. Similarly, the 10 device 222 with another storage device 222a that has been 

server system receives information related to events (e.g., preloaded with an updated version of the databases. This 

sporting events) that it uses to predict link speeds. The server enables the entire database to be updated quickly, for 

system combines these predicted link speeds with link instance, when the main roads network needs to be updated 

speeds reported by probe vehicles when calculating new ^ correspond to a different geographic area, 

routes for in-vehicle systems according to as shortest 15 4.2 Updating Over a High Speed Data Link 

expected travel time criterion. Referring to FIG. 22B, a second approach to updating the 

4 Vehicle Updating (FIGS. 20A-C) in-vehicle system involves transferring data to the in-vehicle 
In the system described above, in-vehicle system and the system over a high-speed (e.g., up to 1 Mb/s) data connec- 

server system include data that is kept consistent. For uon - in-vehicle system includes a data interface 2020 
instance, the main roads network stored in the in-vehicle 20 ^at is connected to onboard computer 210 in in-vehicle 
system includes a subset of the roads network on the server system 105. A source of the update data is connected to the 
system. When the data is consistent, a destination specifi- data interface. For instance, a high-speed connection 2010 
cation that is validated by the in-vehicle system will be valid can be connected to service equipment 2030 at a dealership 
for the server system as well. or a service center which downloads the updated informa- 
nt information used by the overall navigation system is 25 tio ° us j n S J"J«7 sx^^^udM^ pntoc^ siih 
updated from time to time. For example, the map provider as Ford s f SCP or the SAE J1850 protocol. Alternatively an 
may provide periodic updates to the road network to correct ™ n ? : of a v , emcle can a Pf™ 31 2031 
previous errors or to reflect changes in the road network, *"* * a °° m P ute 0 t0 the m-vehicle system. 

such as addition of a new road. U P dates for tae l ^ v f mcl f. Sy ^*n W ° Ul ^ ^o^/ 

30 owner on a recorded medium 2040, sucb as a CD-ROM, or 

Alternative versions of the system use one or more ovef (he MemeU q,,,^ 2011 between the al 

approaches to updating the in-vehicle system to keep the lw and ^ tem can ^ a 

in-vehicle and system databases consistent. When the data- CODneclion ^ as ^ MtiKd link 

bases are consistent a destination specification that is vali- Retening l0 FIG . 2 0C, another alternative approach to 

dated by an in-vehicle system will not be found to be invalid 3J u ^ atin the inJvMat system fc t0 ^ a ^ telephone 

by the server system when it tries to plan a route to the COIlneclion . In this h the in . vehic i e system includes 

destination. Conversely, when the databases are consistent, a modera , e d modem 20so ( & sf> kb/s modem) and 

the in-vebicle wul not rule out a destination specification a , e , hone connector . ^ 0WDer jdes a h ical 

that the server system would have found to be valid, for nectioD 2052 ^ ^ ^ hone , 0 ^ bHc 

example because a new road has been added to the road w teIq)hone network (p STN) 340 . The in-vebicle system 

Dewor * places a telephone call to the server system, or another 

The system also includes the provision to update the server used to provide data updates, and downloads the data 

software in addition to the data for the in-vehicle system. For a t a moderate speed over the telephone connection, 

instance, the user interface for existing functionality can be 43 updating Over a Wireless Link 

changed by downloading new code. Also, entirely new 45 A third approach to updating the ia-vehicle database uses 

functionality can be downloaded. This new or changed a wireless data connections between the in-vehicle system 

functionality can include modified menus and graphics that and the server system, such as over a cellular telephone 

are used to interface with the operator. connection. The amount of data that can be transmitted in a 

New software and interface definitions are integrated into reasonable time (e.g., less than an hour) is limited by the 

the in-vehicle system using one of several well-known 50 relatively slow data transfer speeds that can be achieved 

alternative techniques. For example, new software modules over such connections. Typically, the database is incremen- 

can provide predefined entry points that are accessed from tally updated over a wireless data connection rather than an 

existing software modules in the in-vehicle system. Data entire new copy of the database being downloaded, 

describing the interfaces to new software modules can be One of several alternative approaches to initiating a 

downloaded with the code that implements the modules. 55 database update over a wireless data connection with the 

User interface definitions can be implemented using low- server system are used. First, an operator can explicitly 

level code that manipulates the pixels on the display, or can request an update through the user interface of the in-vehicle 

use a high-level description such as one using a markup system. Second, an update can be requested by an in-vehicle 

language (e.g., HDML). system based on an elapsed time since a prior update. Third, 

The navigation system uses one or more of the following 60 database edits can be downloaded prior to or after down- 
alternative approaches to updating the in-vehicle system: loading a planned route after the in-vehicle system estab- 
. „ , . , . fishes a communication session with the server system. 

Physically replacing a static storage device in the Foufthj me 

server system can place telephone calls to each 

in-vehicle system, of {hc vehicles and « push « the edit updates t0 each vehicle 

Updating over a high-speed data link, for example at a 65 j Q turn. 

dealership or other service center, and i Q or d e r to maintain consistency between the in-vehicle 

Updating over a cellular telephone based data link. data and the server system's data, data in the database is 
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associated with a version number. Each time the server system. This coupling can use standard vehicle data corn- 
system updates its data, it updates the version number. When munication infrastructure found in many vehicles today, 
a vehicle requests a route, it also provides the version such as the SCP (the Standard Corporate Protocol) bus found 
number of the data that was used to validate the destination in vehicles manufactured by the Ford Motor Company, 
specification of the route. The server system uses the 5 5.2.1 Door Unlocking 

received version number to identify which, if any, updates Referring to FIG. 2 IB, remote door unlocking is an 

have not yet been downloaded to the calling vehicle. example of a remote vehicle control service. When an 

The server does not necessarily have to download all operator is locked out of his or her car, he or she contacts the 

updates in one session. Instead, it provides updates incre- server system, for example, by placing a telephone call to a 

mentally. In the incremental approach, the most relevant 10 telephone operator with access to the server system. After 

updates are provided first. For instance, the server system appropriate authentication by the telephone operator, the 

updates the main roads network in the city in which the telephone operator initiates a remote door unlocking proce- 

vehicle typically travels prior to downloading updates for dure that is executed by the server system, 

another city. The vehicle's cellular telephone receiver is not typically 

If an in-vehicle system has an out-of-date database, the 15 left on when the operator has left the vehicle in order to 

validated destination specification that it sends the server reduce battery usage. Therefore, the server system does not, 

system may be invalid due to changes in the road network. in general, simply make a telephone call to the in*vehicle 

For instance, a street name may have changed. Therefore, if system to unlock the doors. 

the server system receives an invalid destination specifica- On a precise schedule, the in-vehicle system repeatedly 

tion from the in-vehicle system, the server system notifies 20 powers up the cellular telephone receiver to determine 

the in-vehicle system which notifies the operator. The opera- whether an incoming call is being placed at that time. For 

tor can then specify another address, or wait for updated instance, the in-vehicle system repeats this cycle every 15 

information to be downloaded to the vehicle from the server minutes. If the in-vehicle system does not detect a call, it 

system. powers down the telephone receiver until the next scheduled 

5 Additional Services 25 listening time. 

In addition to providing navigation services, alternative The vehicle's schedule is stored at the server system, and 

versions of the vehicle information system provide addi- the in-vehicle system and the server system share a common 

tional services such as roadside assistance, remote vehicle time base, for example based on GPS signals. The server 

control, traffic information, and communication related ser- system waits until the locked vehicle's next scheduled 

vices. 30 listening time to make a cellular telephone call to establish 

5.1 Emergency and Roadside Assistance a data communication channel with the in-vehicle system. 
Emergency and roadside assistance provides an operator Once a data connection is established, the server system 

of a vehicle with a way of contacting assistance and pro- sends a command to the in-vehicle system to unlock the 

viding the location of the vehicle. Referring to FIG. 21A, in doors. 

an operator initiated interaction, the operator selects the 35 When the operator of the vehicle requests the door 

emergency and roadside assistance option on the user inter- unlocking service from the telephone operator, the telephone 

face of the in-vehicle system. The vehicle places a cellular operator informs the vehicle operator of the time that the 

telephone call to the server system, or to another server that doors will be unlocked, since the schedule of vehicle lis- 

the in-vehicle system has been configured to call to handle tening times is available to the telephone operator, 

such requests. When the call is established, the in-vehicle 40 5.2.2 Vehicle Immobilization 

system establishes a data connection to the called server. The A vehicle immobilization service uses a similar strategy 

in-vehicle system transfers a unique identification of the as the door unlocking service. A vehicle operator calls a 

vehicle to the server. The unique identification is used by the telephone operator at the centralized server to notify the 

server to access information such as the make, model, and telephone operator that the vehicle has been stolen. The 

color of the vehicle, which may be useful to a dispatched 45 server system can either make a telephone call to the 

service vehicle finding the operator's vehicle. The in-vehicle in-vehicle system immediately, if the telephone receiver in 

system also sends its estimated location, or raw GPS data, the vehicle is powered on, or relies on the scheduled 

and most recent direction of travel based on its GPS mea- power-up mode that is used for the door unlocking func- 

surements. The server system applies GPS correction data to tionality described above. 

the vehicle's estimated location or raw GPS data to deter- 50 In either case, when the in-vehicle system and the server 

mine a corrected location estimate. After the in-vehicle system communicate, the in-vehicle system provides the 

system transfers the data to the server, the operator can vehicle's location to the server system, and the server system 

communicate with a telephone operator 2110 at the server provides to the in-vehicle system a command to disable the 

using the telephone handset in the vehicle. This allows the vehicle. The in-vehicle system then sends a command to a 

operator to provide details that may be useful in dispatching 55 vehicle system to disable the vehicle, 

assistance. 5.3 Traffic Information 

In addition to operator-initiated requests for assistance, The traffic information service provides an operator with 

the in-vehicle system includes a mode in which activation of a report of traffic conditions on a small set of previously 

the air-bag system, or some other indication of an emergency specified "trips." For instance, an operator may have a 

situation, automatically initiates a request for assistance. 60 choice of three alternative ways of getting go from home to 

This mode would be used, for example, if the vehicle is work. When the operator is about to begin the trip, he or she 

involved in a collision and the operator is unable to or does interacts with the in-vehicle system to request traffic infor- 

not think to call for assistance. mation on those trips. The in-vehicle system contacts the 

5.2 Remote Vehicle Control server system, which provides current traffic information for 
Another additional service is remote vehicle control. The 65 the operator's trips. 

in-vehicle system is coupled to vehicle subsystems, such as One approach by which the operator specifies his or her 

the door locking subsystem, or the vehicle control sub- "trips" uses an onboard stored table of a set of trip segments. 
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These segments would typically involve many segments of 
the road network. For instance, a portion of a major highway 
between two intersecting highways might be trip segment. 
The operator "builds" the personal trips by choosing a subset 
of trip segments. When tie in-vehicle system contacts the 
server system to determine traffic conditions on the opera- 
tor's personal trips, the in-vehicle system transfers the 
operator's selected trip segments to the server system. 

The server system uses its traffic database, which include 
current link speeds on segments of the road network, to 
determine the current traffic conditions on the operator's 
trips. Various alternative presentations of the traffic condi- 
tions can be used. In this version of the system, the traffic 
conditions are categorized into a small number of categories, 
such as normal, congested, and severely congested, and each 
category is displayed graphically to the operator using a 
different icon. 

In alternative versions of the system, the server system 
actively contacts a user if an exceptional traffic condition 
occurs on one of the user's previously specified trips. For 
instance, the server system can send the information to the 
in-vehicle system by calling the in-vehicle system, or send 
a pager message, send email, or place a telephone call to the 
user informing the user of the exceptional condition. 

In another alternative, the user specifies several alterna- 
tive trips. When the server system detects an exceptional 
traffic condition on one of the user's specified trips, it 
actively downloads traffic information related to the alter- 
native trips. In this way, the user does not have to wait for 
the in-vehicle system to make a call to the server system to 
replan the route. 

6 Extensible Server Architecture (FIG. 22) 

Referring to FIG. 22, an alternative server system 125a 
provides the functionality of the server system 125 described 
above, and in addition provides an extensible architecture 
for providing other services to the vehicles. Server system 
125a includes multiple server computers coupled over a 
LAN 2205. Alternatively, the functionality of these server 
computers can be implemented on a smaller number of 
computers, or on a single computer that implements all their 
functions. 

Server system 125a includes a gateway system 2210 that 
is coupled to telephone interface 320. Gateway system 2210 
is used to provide a communication gateway between 
vehicles 100 and server computers in server system 125a, 
and implements a message routing function so that commu- 
nication received from an in-vehicle system is directed to the 
appropriate server computer. Gateway system 2210 does not 
necessarily have to interpret the content of data passing 
between the server systems and the vehicles. 

The server computers include a navigation system 2250 
on which the navigation application described above 
executes. When an in-vehicle system initiates a communi- 
cation session with server system 125a to request a route 
planning service, gateway system 2210 determines that the 
session should be connected to navigation system 2250 
using information provided by the in-vehicle system in the 
communication session. For instance, the in-vehicle system 
identifies the navigation service in the initial portion of the 
data stream. Alternatively, different services implemented by 
server system 125a have different telephone numbers that 
are assigned to telephone interface 320, and gateway system 
2210 routes the communication to the appropriate server 
computer based on the number called by the in-vehicle 
system. 

Navigation system 2250 implements the functionality of 
server system 125 as shown in FIG. 5. That is, it includes an 
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interface to GPS receiver 325, and includes server map 
database 520, yellow pages database 522, and traffic data- 
base 524. Navigation system 2250 is coupled to map pro- 
vider 2252, and a traffic information system 2254. 

Another service provided by server system 125a is imple- 
mented by a communication system 2260. Communication 
system 2260 is coupled to external communication systems, 
including an email system 2262 and a paging system 2264. 
These external communication systems forward messages 
addressed to particular vehicles to communication system 
2260. Communication system 2260 requests from gateway 
system 2210 that a data communication channel be estab- 
lished with the particular vehicles, and then passes data and 
commands to the in-vehicle systems. 

The in-vehicle systems in the vehicles include software 
modules that correspond to the services provided by the 
server system. For instance, communication sent from com- 
munication system 2260 to an in-vehicle system is received . 
by a communication module that interprets the data and 
commands it receives. For instance, a message communi- 
cation module displays paging or email messages on the 
display of the in-vehicle system, or alternatively plays them 
as synthesized speech messages. 

A news system 2270 provides a service which sends data 
to vehicles which corresponds to news stories that are of 
interest to a particular vehicle operators. The news stories 
are provided by an external news service 2272. 

Server system 125a also includes a remote configuration 
system 2230 that is coupled to LAN 2205, and that is also 
coupled to the Internet. Using the remote configuration 
system, users of the navigation system can modify their 
records in user profiles 2232 that are stored at the server 
system. A user's profile is downloaded by the server system 
to the in-vehicle system in that user's vehicle, or can 
alternatively be stored on the server system. Information in 
the user profiles can include various types of information, 
including stored destinations that the user can select from 
when specifying a destination to the in-vehicle system. For 
instance, a user can specify a list of frequent destinations 
over the Internet, and then later in the vehicle choose a 
particular destination in that list by selecting from a display 
of the list by the in-vehicle system. 

Another aspect of the user's profile relates to the traffic 
information service. Rather than having to define a set of 
trips using the in-vehicle interface, the user selects trips 
using a graphical map-based interface. For instance, an 
entire map of the highway system or the main roads network 
is displayed. The user selects paths on the graph by selecting 
sequences of trip segments. These trips are downloaded to 
the user's vehicle, or can be stored by the server system. If 
they are stored at the server system, when the user initiates 
a traffic information request in the vehicle, the in-vehicle 
system does not necessarily transfer the specifications of the 
operator's trips, rather it specifies the identity of the operator 
and the server system looks up the operator's stored trips. 

A user's profile can also include preferences such as 
particular roads the user wants to avoid. The user's profile 
can alternatively include a time saving above which the user 
is willing to use a road that he or she otherwise wants to 
avoid. 

A user also uses remote configuration system 2230 to 
input route planning requests. For instance, the user provides 
a destination specification to the remote configuration sys- 
tem and the server system downloads a planned route to the 
destination prior to the user entering the vehicle. The user 
can access the remote configuration system in a variety of 
ways, including over the Internet, and over a voice telephone 
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connection interacting with an automatic speech recognition 
device at the server. In addition to specifying a destination, 
the user can also request notification of when he or she needs 
to start the trip in order to get to the destination at a particular 
time. The notification can be by telephone, pager, or using 
any of a variety of other notification methods. 

A new service is added to server system 125a by adding 
a server computer, updating gateway system 2210 so that 
communication for that service is routed to the new server 
computer, and updating the in-vehicle system by adding a 
corresponding software module to each of the in-vehicle 
systems. The in-vehicle systems are updated either over a 
cellular telephone connection, or over a physical connection, 
as described above (see Section 4). 

Alternative version of the system do not necessarily 
include all the features described above. For instance, a 
traffic information system can include operator specified 
trips. The in-vehicle system contacts a server system for 
traffic information for those trips. The in-vehicle system 
does not need a GPS receiver, or a map database, of other 
features to support this feature alone. 

In another alternative, the in-vehicle system does not 
necessarily support autonomous route replanning. The 
in-vehicle system can contact the server to rep lan the route, 
or to provide a map which it uses to rep lan the route, when 
the in-vehicle system detects that the vehicle has gone 
off-route. 

An alternative version of the system provides a "detour" 
capability. In particular, an operator indicates a road segment 
that should be removed from a planned route, and the 
in-vehicle system plans a detour around that road segment 
using its main roads database. 

In another alternative version of the system, the server 
system plans and downloads several routes, for instance 
planned according to different criteria, such as shortest time, 
shortest distance, etc. The in-vehicle system displays char- 
acteristics of the alternatives (e.g., time, distance) and the 
operator selects one. If the server have not yet downloaded 
al the routes, only the selected route is continued to be 
downloaded. 

In another alternative version of the system, additional 
data is downloaded from the server system along with the 
route. For instance traffic information is downloaded and 
displayed to the operator. Also, advertising information, for 
example, for restaurants along the route are downloaded and 
displayed to the operator and the vehicle passes along the 
route. 

In another alternative, traffic information is downloaded 
to the vehicle, for instance, according to a set of trips that 
have been specified by the operator. The traffic information 
is displayed along with a map of the road network. Traffic 
information is indicated using one of a variety of techniques, 
including text annotations, icons, or using color. 

In another alternative, the server system does not down- 
load spot maps to the in-vehicle system. The in-vehicle 
system provides turn-by-turn instructions from the starting 
locations. For instance, the first instruction may be "proceed 
to street X," accompanied by an arrow indicating the direc- 
tion the street X. 

In another alternative, the in-vehicle system has a main 
roads network for autonomous replanning, but does not 
include address-range data for validating street addresses. 
The in-vehicle system instead relies on the server system to 
validate the street number specified by an operator. In this 
way, the in-vehicle system validates and address partially 
and relies on the server system completing the validation. 

The same server system can concurrently support 
in-vehicle systems with different capabilities, such as the 
alternative capabilities described above. 
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Another alternative version enables an operator to specify 
a sequence of destinations. For example, the first destination 
can be a gas station, and the second destination is the 
operator's work. All the destinations in the sequence are 
validated before the in-vehicle system contacts the server 
system. The server system plans a route from the starting 
location to the first destination, and then from one destina- 
tion to the next. The server system downloads the entire 
planned route to the in-vehicle system. 

It is to be understood that the foregoing description is 
intended to illustrate and not to limit the scope of the 
invention, which is defined by the scope of the appended 
claims. Other embodiments are within the scope of the 
following claims. 
What is claimed is: 

1. A method for vehicle navigation comprising: 
maintaining a first storage for user-specific information 

for each of a plurality of users at a server computer 
system; 

during a first communication session between the server 
computer a system and one of the users, accepting 
user-specific information from the user and storing said 
information in the first storage; 

during a second communication session between the 
server computer system and a navigation system in a 
vehicle, providing navigation information from the 
server computer system to the navigation system at a 
location remote from the server computer system using 
the information previously stored in the first storage, 
and storing the navigation information in a second 
storage accessed locally by the navigation system; and 

during an interactive session between the user and the 
navigation system after termination of the second com- 
munication session, using the navigation system to 
access and process the navigation information stored in 
the second storage, and to provide processed navigation 
information to the user. 

2. The method of claim 1 wherein accepting the informa- 
tion includes accepting user preference information. 

3. The method of claim 2 wherein providing navigation 
information to the user includes determining said navigation 
information according to the user preference information. 

4. The method of claim 3 wherein determining the navi- 
gation information includes determining a route through a 
road network. 

5. The method of claim 4 wherein the user preference 
information includes information related to roads in the road 
network. 

6. The method of claim 5 wherein the information related 
to roads in the road network includes information related to 
roads that the user prefers to avoid. 

7. The method of claim 4 wherein the user preference 
information includes information characterizing a tradeoff 
between time savings and particular roads in the road 
network. 

8. The method of claim 1 wherein accepting the informa- 
tion includes accepting information from a user related to 
one or more destinations. 

9. The method of claim 8 wherein the information related 
to the destinations includes specifications of locations of 
said destinations. 

10. The method of claim 8 wherein the information 
related to the destinations includes routes through a road 
network to said destinations. 

11. The method of claim 8 wherein providing the navi- 
gation information includes accepting a selection from the 
user through the navigation system of a particular one of the 
destinations. 
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12. The method of claim 11 wherein providing the navi- 
gation information includes planning a route at the server 
computer system to the selected destination. 

13. The method of claim 12 wherein providing the navi- 
gation information further includes communicating the 
planned route to the navigation system. 

14. The method of claim 13 wherein communicating the 
planned route to the navigation system includes passing data 
characterizing to planned route from the server computer 
system to the in-vehicle system. 

15. The method of claim 8 wherein the information 
related to one or more destinations includes a specification 
of a route to one of the destinations. 

16. The method of claim 8 wherein the information 
related to the one or more destinations includes a desired 
arrival time at one of the destinations. 

17. The method of claim 16 wherein providing navigation 
information includes notifying the user of a departure time 
based on the desired arrival time. 

18. The method of claim 17 wherein providing navigation 
information further includes computing the departure time 
using an estimated travel time to the destination. 

19. The method of claim 16 wherein providing navigation 
information includes notifying the user at a time based on 
the desired arrival time. 

20. The method of claim 19 wherein providing navigation 
information includes notifying the user according to an 
estimated travel time to the destination. 

21. The method of claim 20 wherein notifying the user 
includes notifying the user prior to a required departure time 
to reach the destination by the desired arrival time. 

22. The method of claim 19 wherein notifying the user 
includes notifying the user over a communication system. 

23. The method of claim 22 wherein notifying the user 
over a communication system includes notifying the user 
over a paging system. 

24. The method of claim 22 wherein notifying the user 
over a communication system includes notifying the user 
over a telephone communication system. 

25. The method of claim 1 wherein accepting the user- 
specific information includes accepting said information 
over a communication network. 

26. The method of claim 25 wherein accepting the infor- 
mation over a communication network includes accepting 
said information over a data communication network. 

27. The method of claim 26 wherein accepting the infor- 
mation over a data communication network includes accept- 
ing the information over the Internet. 

28. The method of claim 26 wherein accepting the infor- 
mation includes providing a graphical interface to a user. 

29. The method of claim 25 wherein accepting the infor- 
mation over a communication network includes accepting 
said information over a telephone communication network. 

30. The method of claim 29 wherein accepting the infor- 
mation includes using a speech recognition device to inter- 
pret signals received over the telephone communication 
system. 

31. Software stored on computer readable media com- 
prising instructions for causing a computer system to: 

maintain a first storage for user-specific information for 
each of a plurality of users at a server computer system; 

during a first communication session between the server 
computer system and one of the users, accept informa- 
tion from the user and store said information in the first 
storage; 

during a second communication session between the 
server computer system and a navigation system of a 
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vehicle, provide navigation information from the sewer 
computer system to the navigation system at a location 
remote from the server computer system using the 
information that was accepted from said user, and 
storing the navigation information in a second storage 
accessed locally by the navigation system; and 
during an interactive session between the user and the 
navigation system after termination of the second com- 
munication session, use the navigation system to access 
and process the navigation information stored in the 
second storage, and provide processed navigation 
information to the user. 

32. A vehicle navigation system comprising: 

means for maintaining a first storage for user-specific 
information for each of a plurality of users at a server 
computer system; 

means for accepting information from one of the users 
and for storing said information in the first storage; 

means for providing navigation on information from the 
server computer system to a navigation system of a 
vehicle at a location remote from the server computer 
system using the information that was accepted from 
said user, and storing the navigation information in a 
second storage accessed locally by the navigation sys- 
tem; and 

means for, during an interactive session between the user 
and the navigation system, using the navigation system 
to access and process the navigation information stored 
in the second storage, and providing processed navi- 
gation information to the user. 

33. The method of claim 1, further comprising, during or 
alter the interactive session, initiating a communication 
session between the server computer system and the navi- 
gation system to request additional navigation information 
from the server computer system, the communication ses- 
sion initiated by the navigation system and without a request 
from the user to initiate such communication session. 

34. The method of claim 33 wherein the additional 
information requested includes more detailed map informa- 
tion, 

35. The method of claim 33 wherein the communication 
session is initiated when the vehicle deviates from a pre- 
planned route. 

36. The method of claim 1 wherein the interactive session 
comprises the user removing a road segment from a planned 
route and the navigation system planning a detour around 
the road segment. 

37. The method of claim 1 wherein the interactive session 
comprises the user providing two locations and the naviga- 
tion system providing turn-by-turn instructions for traveling 
from one location to the other location. 

38. The method of claim 2, further comprising providing 
user-preference information from the server computer sys- 
tem to the navigation system based on the information stored 
in the first storage, and storing the user-preference informa- 
tion in the second storage. 

39. A method for vehicle navigation comprising: 
accepting user-preference information from a user and 

storing the user-preference information in a first storage 
at a server computer system; 
providing part or all of the user-preference information 
from the server computer system to a vehicle naviga- 
tion system at a location remote from the server com- 
puter system using the information stored in the first 
storage, and storing the user-preference information in 
a second storage accessed locally by the vehicle navi- 
gation system; and 
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during an interactive session between the user and the 
vehicle navigation system, using the vehicle navigation 
system to provide navigation information based on the 
user-preference information stored in the second stor- 
age. 

40. The method of claim 39, further comprising, during or 
after the interactive session, initiating a communication 
session between the server computer system and the vehicle 
navigation system, and providing additional navigation 



42. The method of claim 40 wherein the communication 
session is initiated when the vehicle deviates from a pre- 
planned route. 

43. The method of claim 40 wherein the additional 
information includes re-routing information. 

44. The method of claim 39 wherein the interactive 
session comprises the user removing a road segment from a 
planned route and the navigation system planning a detour 
around the road segment. 

45. The method of claim 39 wherein the interactive 



information from the server computer system to tbe vehicle to session comprises the user providing two locations and the 

navigation system. navigation system providing turo-by-turn instructions for 

41. The method of claim 40 wherein the additional traveling from one location to the other location, 
information requested includes more detailed map informa- 



tion. 
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